Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
Feb 08, 2018

AFM 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?

 

Piotr

 

AFM
afm policy
application delivery
devops
network address translation
pat
performancel4
  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    Feb 08, 2018

    I can't as well understand tcpdump on VIP VLAN. After receiving SYN to VIP:887 I can see plenty of ARP request sourced from self IP on the VIP VLAN. Those are not replied.

    Why BIG-IP is sending ARP request for VIP on the same BIG-IP?

    19:05:01.324186 IP 192.168.176.159.11000 > 192.168.177.21.887: Flags [S], seq 1886485909, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 in slot1/tmm1 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=4 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0

19:05:01.324709 ARP, Request who-has 192.168.177.21 tell 192.168.177.253, length 112 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=1 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0
19:05:02.324409 ARP, Request who-has 192.168.177.21 tell 192.168.177.253, length 112 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=1 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0
19:05:03.324074 ARP, Request who-has 192.168.177.21 tell 192.168.177.253, length 112 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=1 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0
19:05:04.324039 ARP, Request who-has 192.168.177.21 tell 192.168.177.253, length 112 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=1 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0

19:05:04.330834 IP 192.168.176.159.11000 > 192.168.177.21.887: Flags [S], seq 1886485909, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 in slot1/tmm1 lis=/Common/tmg-nat_vs flowtype=65 flowid=5700D0B97F80 peerid=5700D0B98080 conflags=1002010000202A4 inslot=1 inport=4 haunit=0 priority=3 peerremote=00000000:00000000:0000FFFF:C0A8B115 peerlocal=00000000:00000000:0000FFFF:C0A8B09F remoteport=80 localport=6893 proto=6 vlan=377

19:05:05.324016 ARP, Request who-has 192.168.177.21 tell 192.168.177.253, length 112 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=1 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0
19:05:06.323872 ARP, Request who-has 192.168.177.21 tell 192.168.177.253, length 112 out slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=1 inport=1 haunit=0 priority=3 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0

19:05:09.324209 IP 192.168.177.21.887 > 192.168.176.159.11000: Flags [R.], seq 0, ack 1886485910, win 0, length 0 out slot1/tmm1 lis=/Common/tmg-nat_vs flowtype=65 flowid=5700D0B97F80 peerid=5700D0B98080 conflags=1002010000202A4 inslot=1 inport=4 haunit=1 priority=0 rst_cause="[0x23f0b6d:284] handshake timeout" peerremote=00000000:00000000:0000FFFF:C0A8B115 peerlocal=00000000:00000000:0000FFFF:C0A8B09F remoteport=80 localport=6893 proto=6 vlan=377
    • 168.176.159 - client IP
    • 168.177.21 - VIP
    • 168.177.253 - Self IP

    Piotr

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Feb 08, 2018

    Hi fellow MVP,

     

    I don't have much familiarity with AFM i'm afraid, and certainly not the Translation rules. Anyway, the general configuration doesn't look right to me. A Perf L4 server, when it receives its initial SYN packet from the client, will choose a target and send the SYN onto this. This is normally a pool member (see Overview of TCP connection setup for BIG-IP LTM virtual server types). I suspect you're getting a reset, after a few SYNs, because the BIG-IP doesn't have a pool so can't send the packet on. In fact, the ARP requests you are seeing is because without the pool it's acting like a Forwarding IP virtual and wants to send the packet onto the VIP address and the BIG-IP doesn't respond to its own ARP requests (see A local virtual server IP address cannot be used as a pool member

     

    Can you not let the LTM deal with the address translation and just use AFM for firewall policies, i.e. what source addresses are allowed etc.

     

    Hope this helps,

     

    N