pat
2 TopicsPort Translation & HTTPS -> HTTP
Systeminformation: F5 BIG-IP r2600 Version 17.1.1.1 Build 0.0.2 Hello everyone, We would like to map the following scenario with the f5 BIG-IP I call https://server.domain.com port 443. The BIG-IP should then forward to http://server.domain.com port 55000. Is this even possible? How did you solve it? Configuration: For port translation, we entered port 443 in the virtual server and gave the pool member port 55000. For HTTPS to HTTP we used the following iRule: when HTTP_REQUEST { # Extrahiere den Host und den URI aus der HTTPS-Anfrage set host [HTTP::host] set uri [HTTP::uri] # Leite die Anfrage an die HTTP-Version der gleichen URL weiter HTTP::respond 301 Location "http://$host$uri" log "iRule_HTTP, HTTPS-Anfrage wurde auf HTTP umgeleitet: $host$uri, ClientIP: [IP::client_addr], ClientPort: [TCP::client_port]" } Is the iRule log entry generated before the port translation? The wrong port is in the logs. Best regardsSolved65Views0likes2CommentsAFM NAT - how to implement
Hi, That is probably something easy and I have to be missing tiny detail but as for now I am stuck :-( I need to create something that I think is classic FW NAT. My goal is like that: Single VIP on BIG-IP Client connecting to VIP port X is NATed to backend IP Y port X (other option is changing port on backend) Client connecting to VIP port Y us NATed to backend IP Z port Y, and so on What I did: Created PerformanceL4 VS with all ports, no pool, no SNAT, Address and Port Translation checked Created AFM NAT policy like on image below Assigned this policy to VS via Security > Policies: Network Address Translation, Policy option (Use Device Policy and Use Route Domain Policy unchecked) Unfortunately it's not working. When connecting to VIP:887 from client I am getting RST (not immediately, most often after 2-3 SYN retries). Notice that my NAT policy is reporting hits, so seems that client side part is working but not server side. I can of course ping (and do HTTP connection) to IP:port listed as Translated Destination. When checking show net rst-cause I can't see any related (at least in my opinion) causes - only increasing counters are: VIP disabled (administrative) handshake timeout - that might be related? There is counter named (FW NAT) dst_trans failed. but it shows 0 Maybe another clue is that client after first SYN is receiving ICMP Host unreachable from BIG-IP floating IP on the VIP VLAN. I can't see as well any traffic on backend side. Even ARP request for Translated IP. So what I am doing wrong? Another question is if I need separate AFM Network policy for such VIP - I mean to control allowed destination ports or having just AFM NAT policy is enough (seems that it as well allows to control Source IP so even for that AFM FW policy should not be needed). In other words if there is incoming traffic to port not defined in AFM NAT policy will it be anyway rejected or not? Piotr442Views0likes2Comments