nat
16 TopicsNAT for specific IPs
Hi All, Looking for suggestions on how I can accomplish NAT for a couple of specific IPs, without NATting all the incoming traffic. My scenario is as following: source client ips 10.10.10.100 & 10.10.10.102 destination VS1(10.10.20.1.), load balancers to servers 10.10.10.10 & 10.10.10.20 (same subnet as the source address). I would like to NAT traffic from these client addresses to the floating IP 10.10.10.1, and all other client traffic no NAT is applied. I can't create a NAT Pool for 10.10.10.100 & 10.10.10.102 as they are members of pool for a different VS. Any ideas/suggestions on how I can accomplish this? I appreciate your assistance. Thanks DeenaSolved41Views0likes1CommentAPM - How to configure logging of snat addresses for network access and app tunnels
Hello everyone, we are using BIG-IP Access Policy Manager to enable administrative access to systems via App Tunnel and Network Access resources. For security reasons, we need to be able to map requests logged on backend resources/systems (e.g. in SSH audit logs) to the session or user accessing said backend resource via App Tunnel or Network Access in APM. Currently, the following request information is logged. Network Access: May 17 14:42:00 tmm0 tmm[22565]: 01580002:5: /APM/ap_rmgw:Common:c1237463: allow ACL: #app_tunnel_/APM/Some_App-Tunnel@c1237463:15 packet: tcp 192.168.12.18:58680 -> 10.0.0.1:22 App Tunnels: May 17 14:41:10 tmm1 tmm1[22565]: 01580002:5: /APM/ap_rmgw:Common:c6787463: allow ACL: #app_tunnel_/APM/Some_App-Tunnel@c6787463:0 packet: tcp 89.229.152.144:63252 -> 10.0.0.1:2 For Network Access requests, an IP address of the lease pool configured in the Network Access resource is logged as the client IP. For App Tunnel requests, the public IP of the client accessing APM is logged as the client IP. In our setup, both requests will be NATed by APM before hitting the target system (through a snat pool in case of a Network Access request, through the active appliances backend IP in case of App Tunnels). Therefore, the APM self IPs (snat pool/appliance backend) will be logged on the target host, leading to us not being able to correlate logs in APM with logs on the target systems. Is there any way to log the SNAT/NAT addresses and ports used to access target systems through APM? I've tried using ACCESS_ACL_ALLOWED in an iRule to log additional information, unfortunately this event only seems to trigger on Portal Access resources, not when using App Tunnels or Network Access resources. Thank you, Fabian2.1KViews0likes1CommentSNAT and NAT on difference vlans
Hi, I have a few questions about SNATs and NAT's and trying to get traffic to either SNAT or NAT based on the destination. Here's the diagram: I want traffic from 10.8.4.26 destined to 10.8.8.0/24 to use a SNAT of 10.8.8.22. I want traffic from 10.8.4.26 destined to 10.8.6.0/24 to use a NAT of 10.8.6.26. I also want traffic from 10.8.6.0/24 to be able to reach 10.8.4.26 on TCP/5600. Here's what I've tested: Configured NAT for 10.8.4.26 <> 10.8.6.26, enabled on Pubdmz vlan only. a. Ping works from internal (10.8.4.26) to pubdmz (10.8.6.104). NAT is correctly applied. b. Inbound connection from 10.8.6.104 to 10.8.6.26:5600 works c. Ping fails from 10.8.4.26 to 10.8.8.78 (external). 10.8.8.78 sees traffic from 10.8.6.26 NAT address. This would be expected at this point since no other configuration has been applied. Tried configuring second NAT for 10.8.4.26 <> 10.8.8.26 enabled on external only a. Configuration failed with error "Requested origin address already exists. Since I couldn't create second NAT, I deleted first NAT and tried VS with iRule. Created new irule data group called 'external_network' and added 10.8.8.0/24 as a record. Created new virtual server: a. Name: vs-internal-networks b. Source: 10.0.0.0/8 c. Destination: 0.0.0.0/0.0.0.0 d. Enabled on Internal e. All protocols Created new iRule called 'check_destination_snat' with following code: when CLIENT_ACCEPTED { if {[class match [IP::local_addr] equals external_network] } { snat 10.8.8.22 } } Tried to ping 10.8.8.78 from 10.8.4.26. tcpdump on destination host shows that traffic is being SNAT'd, but when server attempts to ARP for SNAT address, nothing answers, so no response is ever sent. Added SNAT list called 'external-10.8.8.22, enabled on external interface. Tested ping again and this time was successful. Tried pinging pubdmz network again, but this failed due to lack of NAT. (Destination host saw traffic from original IP address) Added NAT back for 10.8.4.26 <> 10.8.6.26 enabled on Pubdmz only. Tried pinging without success -- destination host still saw traffic from original IP. Ping to 10.8.8.78 still works, and SNAT is correctly applied. This setup leads me to a few questions: We know that the LTM will evaluate objects in the order of VS > SNAT > NAT before routing. Is there a way to tell an irule to stop processing and then have the traffic move to the next item in the list? In this case, I'd want the VS to check if it can apply a SNAT, and if not, move on to check the NAT list. From step 2, does that error mean that an origin address can only appear in one NAT rule system-wide?745Views0likes15CommentsPersistence issues when using two different Virtual servers for the same traffic
Here is the scenario that I have: Virtual Server A is set up with an a simple application portal that sends all external clients/users from https://website.org (external) to https://server/website.org which is on another Virtual Server B on the same F5. We use to have another load balancer and we replaced it using the same F5. So i am sending https traffic from one virtual server to another and trying to use cookie persistence but i think that the SSL is preventing any cookie insert. Basically my second virtual server B only sees the IP of the internal float IP and treats all traffic as one user so i don't get traffic to all pool members. I am hoping that there is some kind of fix to this or will i have to redesign my first virtual server to not go to another virtual server and just load balance it's own pool members.778Views0likes5CommentsNAT not working after software update
Hi there, long time ago, that I had a question here. I'm currently working on a F5 project, where we have to perform a hardware refresh including a software update. The old environment consists of two LTM-pairs, one without Route Domains and the second with two Route Domains. The old platform is running on 10.2.4. The new environment consists only of one LTM-pair now with three Route Domains (all consolidated into one cluster). The new platform is running on 14.1.1. All VS, NATs and floating-IPs are identical, means we first isolated the old environment (by disabling the tmm-interfaces) and then enabled the new environment. During migration our pain point was, that the configured NATs were not working correctly and I'm now wondering of there is maybe a change in behavior or if we made something wrong. As an example, we saw the following result with tcpdump. Configured NAT xxx.189.21.151 origin 192.168.35.51 Old working environment: 03:22:10.884644 IP xxx.189.5.152 > 192.168.35.51: ICMP echo request, id 15796, seq 980, length 64 03:22:10.884920 IP xxx.189.21.151 > xxx.189.5.152: ICMP echo reply, id 15796, seq 980, length 64 New not working environment: 03:21:14.934663 IP xxx.189.5.152 > xxx.189.21.151: ICMP echo request, id 15796, seq 125, length 64 in slot1/tmm0 lis= 03:21:15.940626 IP xxx.189.5.152 > xxx.189.21.151: ICMP echo request, id 15796, seq 126, length 64 in slot1/tmm0 lis= So from this output it looks like, that the ICMP echo request will not correctly translated to the origin address. Is this true or how can I interpret this? How can I verify that NATing is correctly working? Or do I have to check any additional (new) settings? Or is this maybe any kind of ARP-issue (how can I force the new LTMs to propagate its new MAC-addresses)? In case you require more details about the setup, please let me know. Thank you! Ciao Stefan :)560Views0likes5CommentsAFM Firewall and NAT policies - how to implement
Hi, I need to implement policies for few hundreds src IP, dst IP SNAT and NAT combinations. Something like that, all related to 13.1.0.1: For given dst IP: Allow traffic from given set of IPs For given set of dst ports change dst IP (sometimes as well as port) to given IP For given dst IP there could be dozens of such rules. I am looking for real life advice which way would be better - maybe because of aspects I am not aware off, like easier troubleshooting, easier log checking anything else. Right now I can see two ways to implement: One wildcard IP and port VS One FW policy containing all source/destination definitions One NAT policy containing all destination port/destination IP and port definitions One VS per each destination IP (so FW rules do not need to check destination IP only source IP) One FW policy containing all source/destination definitions related to this dst IP One NAT policy containing all destination port/destination IP and port definitions In first case I will have single policies with hundreds of rules (or rule lists in case of FW policy) - seems harder to figure out what is in fact configured (sure filtering can be used) In second case it is easier to figure out what was set for given destination IP I am a bit lost here what would be better for real life management, maintenance and troubleshooting. What is complicating things even more some configuration has to be repeated for both FW and NAT policy. For example (at least in my test) NAT policy has to have Destination IP configured (same one as in Firewall policy). I can understand the reason for that but it makes space for mistakes, for example different dst IP in FW policy that in matching NAT policy. I hoped it could be resolved by applying NAT policy to VS - so it automatically pick up VIP and will use it as destination, but it seems not be a case. Any advice highly appreciated. Piotr394Views0likes3CommentsVS and NAT precedence
Hi, I was under impression that when there is NAT and VS defined (both matching incoming packet) then VS always wins. That is the case for SNAT - except when Source Address Translation is set to None on VS and matching SNAT object exists. But still for SNAT there is full control if SNAT should be used or not (even if SNAT is None on VS, we can set Allow SNAT No on Pool). Problem is that there seems to be no such control for NAT. Scenario: Network VS Forwarding (IP) type Source Address: 10.1.20.252/32 Destination Address/Mask: 192.168.104.0/24 Service Port: All Source Address Translation: None Enabled On: VLAN int NAT object Origin Address: 10.1.20.252 NAT Address: 10.128.11.51 Host sending traffic to 192.168.104.0/24 subnet Host IP: 10.1.20.252 - matching both NAT Origin Address and VS Source Address Def GW: BIG-IP Self IP on VLAN int Result: All traffic leaving BIG-IP on VLAN ext has src IP NATed to 10.128.11.51 (NAT Address). What's more, looking and NAT and VS stats it's obvious that traffic is processed by both VS and NAT (same packet count reported on both). Wonder if it is expected behavior? If so it seems that there is no way to prevent NATing src IP for such configuration - only way is to set NAT object to disabled - seems to be a little drastic solution. Piotr311Views0likes1CommentVS and NAT precedence
Hi, I was under impression that when there is NAT and VS defined (both matching incoming packet) then VS always wins. That is the case for SNAT - except when Source Address Translation is set to None on VS and matching SNAT object exists. But still for SNAT there is full control if SNAT should be used or not (even if SNAT is None on VS, we can set Allow SNAT No on Pool). Problem is that there seems to be no such control for NAT. Scenario: Network VS Forwarding (IP) type Source Address: 10.1.20.252/32 Destination Address/Mask: 192.168.104.0/24 Service Port: All Source Address Translation: None Enabled On: VLAN int NAT object Origin Address: 10.1.20.252 NAT Address: 10.128.11.51 Host sending traffic to 192.168.104.0/24 subnet Host IP: 10.1.20.252 - matching both NAT Origin Address and VS Source Address Def GW: BIG-IP Self IP on VLAN int Result: All traffic leaving BIG-IP on VLAN ext has src IP NATed to 10.128.11.51 (NAT Address). What's more, looking and NAT and VS stats it's obvious that traffic is processed by both VS and NAT (same packet count reported on both). Wonder if it is expected behavior? If so it seems that there is no way to prevent NATing src IP for such configuration - only way is to set NAT object to disabled - seems to be a little drastic solution. Piotr170Views0likes0CommentsNAT and Enabled On
Hi, I tried to figure out how Enabled On works for NAT entries (v13 VE). I am a bit surprised by results and would like to find out if this is kind of bug or correct behavior. Scenario: Two vlans: ext, int NAT with: NAT Address in ext vlan, NAT Origin Address - IP of host_int in int vlan Results for Enabled On All - communication from/to host_int working ext - communication from/to host_int working - why? I understand why communication to host is working but why from host (initiated by host_int) int - no communication working, target host in ext vlan is receiving for example ping request but ARP request to resolve NAT Address MAC is not working - no reply from BIG-IP. Seems a bit strange but maybe there is logic here. Same if host in external vlan tries to reach host_int (see as well notes at the end) no vlan - no communication working - that is expected One issue not directly related to BIG-IP. Is that usual host behavior to issue ARP request for src IP of ping request? After receiving ping request target host knows MAC of src IP. Is that kind of security measure to verify if src MAC in ping request really exists on attached network? Of course it's done when there is no MAC in ARP cache? Win 2008 Srv target host. Strange is that when MAC is in ARP cache on target host reply is returned - BIG-IP is passing it back to host_int (case with NAT Enabled on int vlan). But right after this reply MAC is removed from ARP cache. Next request triggers ARP resolution but it fails and reply is not send back. If MAC is added as static entry on target host then communication from host_int is working (no ARP resolution is needed so target host knows where to send reply) Communication to host_int is not working in this case - seems that BIG-IP is silently dropping ping request send to NAT Address. Another issue noticed: when two different NAT entries were created (IPs in the same subnets as described) and one of them was set to Enabled on - no vlan and latter on even disabled then another stopped to work - there were no ARP replies send from BIG-IP for this second NAT address. After removing second NAT entry everything started to work - is that normal, or maybe just behavior on VE? Piotr342Views0likes1CommentProblem for implement NAT with VPN IPsec
Hello, I have a IPsec VPN (IKE Peers) with different partner. The problem is when we try to use NAT for the different VPN Tunnel, the different IPs are not translated. For exemple we want to configure : -Static NAT : one IP translated on one other IP _ 10.10.10.1 to 192.168.1.1 for exemple -Dynamic NAT : one range of IP translated to an other range _ 10.10.10.0 /24 -> 192.168.1.0 /24 for exemple -PAT : one range of IP translated on one IP _ 10.10.10.0 /24 -> 192.168.1.1 for exemple Could you help me please because the translation don't work. Thanks a lot.259Views0likes1Comment