Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
May 30, 2017

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

Hi,

 

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: 10.128.30.0/24 - internal VLAN subnet
    • Translate: SNAT pool with 10.129.10.40 - 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 10.129.10.13)
    • Enabled on: internal VLAN (10.128.30.0/24)
    • Pool with member pointing to IP defined as well as default gateway in Routes - 10.129.10.2
  • Ping performed from 10.128.30.152 IP to 10.129.10.2

Results:

 

  • tcpdump reports that ping is processed by wildcard VS
  • Flows created:
    • 10.128.30.152 -> 10.129.10.2
    • 10.129.10.13 (floating self IP) -> 10.129.10.2
  • 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 (10.129.10.13) not SNAT object IP (10.129.10.40)

 

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

Same setup as above

 

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

Results:

 

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

If:

 

  • Floating self IP is pinged (10.129.10.13), 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.

 

Scenario:

 

  • telnet from internal VLAN host - 10.128.30.152 - (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?

 

Piotr

 

2 Replies

  • 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:

    10.128.30.151:123 194.146.251.101:123 10.129.10.13:123 194.146.251.101:123 udp 169 (tmm: 0) 192.168.1.2:51914 192.168.1.1:1026 192.168.1.2:51914 192.168.1.1:1026 udp 0 (tmm: 0) 192.168.1.1:38978 192.168.1.2:1026 192.168.1.1:38978 192.168.1.2:1026 udp 0 (tmm: 0) 10.128.40.239:56372 10.128.40.110:8081 10.128.40.239:56372 10.128.40.110:8081 tcp 0 (tmm: 0)

    So sure there are connections from subnet set in SNAT object (10.128.30.0/24) but those are handled by wildcard VS (server side src IP 10.129.10.13 - 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.

    Piotr

  • Hi,

     

    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.

     

    Pedro