Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology

Strange issue with SNAT stats, pinging self IP and Allow None


I am running out of ideas why BIG-IP behaves as in cases described below, either it's my lack of knowledge, expected behavior or bug.

Tested on v11.2.0HF7 Active-Passive cluster.

Case 1 - SNAT stats increased even if SNAT object not used

  • SNAT object defined with:
    • Origin: - internal VLAN subnet
    • Translate: SNAT pool with - ip from external VLAN subnet
    • Enabled on: internal VLAN
  • Wildcars VS defined with:
    • Performance L4
    • All ports
    • All protocol
    • SNAT: Automap (using floating self IP
    • Enabled on: internal VLAN (
    • Pool with member pointing to IP defined as well as default gateway in Routes -
  • Ping performed from IP to


  • tcpdump reports that ping is processed by wildcard VS
  • Flows created:
    • ->
    • (floating self IP) ->
  • SNAT object stats are increased when ping is send

If SNAT object is set to Enabled on with empty Selected stats are not increased.

Question is why SNAT object stats are increased if packets are processed by wildcard VS and src IP on external VLAN is translated to floating Self IP ( not SNAT object IP (

Case 2 - ping from internal VLAN to external self IP receives replies

Same setup as above

  • Ping from to (self IP on external VLAN)
  • No VS defined with IP at all


  • Ping is answered
  • tcpdump reports wildcard VS as the one processing ping


  • Floating self IP is pinged (, still wildcard is listed as listener processing ping but there is no reply
  • Any other self IP from other configured VLANs is pinged - as above - no answer

Why self IP on external VLAN replies to pings?

Case 3 - Allow none set on VLAN used for Mirroring and Config sync

According to all articles and manuals I saw, there are port exceptions no matter what Port Lockdown is set for self IP. Those are Mirroring port (1028), Config Sync port (4353) and ICMP.

For HA related ports,t there is as well note that those are open for packets received from peer IP - at least that is my understanding.


  • telnet from internal VLAN host - - (both Config Sync and Mirroring are configured to use internal VLAN self IP) is launched to port 4353
  • tcpdump shows that there is proper 3WHS performed between host and self IP
  • telnet from internal VLAN host to self IP port 1028 is launched
  • immediately BIG-IP sends RST

Why 4353 is accepting connection and 1028 is not - both connections are performed from the same IP - one that is not peer IP.

That could be especially in case of Config Sync port. If anyone in the same network as self IP used for Config Sync can setup TCP connection, then he can as well send crafted packets that will break syncing process - at least it seems so.

So port exceptions in HA are accepting connections only from peer IP or from any IP in the same subnet as self IP?


Rate this Question
Comments on this Question
Comment made 31-May-2017 by Piotr Lewandowski 1162

Regarding SNAT issue, can anyone explain ehat this output means:

show ltm snat LAMP_subnet_to_ext detail

Ltm::SNAT: LAMP_subnet_to_ext
Traffic                ClientSide
  Bits In                   30.5K
  Bits Out                  29.7K
  Packets In                   82
  Packets Out                  82
  Current Connections           1
  Maximum Connections           5
  Total Connections            19

  | Ltm::SNAT Pool: SNAT_to_Internet_pl
  | Traffic                ServerSide
  |   Bits In                       0
  |   Bits Out                      0
  |   Packets In                    0
  |   Packets Out                   0
  |   Current Connections           0
  |   Maximum Connections           0
  |   Total Connections             0

SNAT object is using SNAT Pool, SNAT pool is not seeing any traffic (so no src IP translations) but SNAT object sees traffic and even has open connections.

But when doing tmsh show sys connections there are only connections like that: udp 169 (tmm: 0) udp 0 (tmm: 0) udp 0 (tmm: 0) tcp 0 (tmm: 0)

So sure there are connections from subnet set in SNAT object ( but those are handled by wildcard VS (server side src IP - floating self ip - snat automap).

So what's going on here?

Stats stops to increase when I set Disable On in SNAT with internal VLAN selected. Is I have Enabled on with empty Selected then stats are still increasing.



Answers to this Question



Remember that there are multiple types of listeners, so the order of precedence is as follow:

  • Connection table
  • Packet filters
  • Destination “listener” (i.e. Virtual Server)
  • IP : port
  • IP : * (all ports)
  • NW : port
  • NW : *
  • * : port
  • * : * (wildcard virtual server)
  • Source “listener” (SNATs not in VS)
  • Single IP
  • Network
  • All Addresses
  • NATs

So first BIG-IP system check if there's an entry in the connection table. By default PF don't affect existing connections, but they can be changed to filter existing connections. Next we have the destination listeners or VSs, and then our source listeners (SNATs). Within both destination and source listeners, they can be configured more or less specific. Finally we process NATs.

I hope this helps.


Comments on this Answer
Comment made 01-Jun-2017 by Piotr Lewandowski 1162


I know all of that, problem is how this applies to situation I described?

We starting with no entries in session table

No traffic processed by destination listener - wildcard VS - so stats empty for VS

No traffic processed by source listener - SNAT object - so empty for SNAT

Now sending single ping from to IP behind BIG-IP (so going via BIG-IP internal self IP - def gw for host)

Result is that both wildcard stats increase and SNAT object stats increase but SNAT translation is not using IP from SNAT object but external Self IP (wildcard VS has automap defined).

So what traffic processing is performed by SNAT object?

According to precedence you listed traffic is captured by destination listener object - wildcard VS - so should not ever be processed by SNAT - at in fact thats the case!

Sure if wildcard VS would have SNAT set to none that SNAT object would kick in and perform src IP translation - but this is not the case.

But still stats of SNAT suggest something opposite, what those client side stats for SNAT mean - that SNAT seen packets that it could potentially process but because of other higher precedence objects had to give up - that's why no stats on server side (SNAT Pool)?

That is quite misleading isn't it?