Forum Discussion

Carlos_123412's avatar
Carlos_123412
Icon for Nimbostratus rankNimbostratus
Oct 23, 2015

Strange SNAT IP address behaviour

Hello everyone,

 

Recently we've discovered a weird behaviour on our BIG-IP system. We are currently running version 11.5.1 on an 8950 Active/Passive HA pair.

 

We have detected that a couple of servers, due to misconfiguration, are generating UDP traffic to port 1002 of an SNAT IP address which belongs to a SNAT Pool. Our BIG-IP is bouncing that traffic back to the network simply changing source an destination MAC address on the ethernet header.

 

You can see it on the following screenshots:

 

 

 

Is this an expected behaviour? Shouldn't F5 just drop this traffic?

 

As additional info: the VS to which this SNAT Pool belongs is configured for port 80 HTTP.

 

Thank you very much in advance for your answers.

 

Best regards, Carlos

 

9 Replies

  • Can you provide the config for the virtual server and SNAT pool, as well as a list of any SNATs on the system, please?

     

  • Hello Cathy,

    Thanks for your answer. This are the two VS that are using the SNAT Pool. As for the rest of the SNATs all of them are like this one, we've got about 319 SNAT pools. For privacy reasons I've changed VS name and obcured IP addressess.

    ltm virtual /Common/virtual_server_1_80 {
        destination /Common/XX.XX.41.86:80
        ip-protocol tcp
        mask 255.255.255.255
        persist {
            /Common/ip_origen_3600 {
                default yes
            }
        }
        pool /Common/Pool_virtual_server_1_80
        profiles {
            /Common/http { }
            /Common/tcp_3600 { }
        }
        source 0.0.0.0/0
        source-address-translation {
            pool /Common/virtual_server_1_snatpool
            type snat
        }
        translate-address enabled
        translate-port enabled
    }
    
    ltm virtual /Common/virtual_server_1_8081 {
        destination /Common/XX.XX.41.86:8081
        ip-protocol tcp
        mask 255.255.255.255
        persist {
            /Common/ip_origen_3600 {
                default yes
            }
        }
        pool /Common/Pool_virtual_server_1_8081
        profiles {
            /Common/tcp_3600 { }
        }
        source 0.0.0.0/0
        source-address-translation {
            pool /Common/virtual_server_1_snatpool
            type snat
        }
        translate-address enabled
        translate-port enabled
    }
    
    
    
    ltm pool /Common/Pool_virtual_server_1_80 {
        members {
            /Common/XX.XX.XX.225:80 {
                address XX.XX.XX.225
            }
            /Common/XX.XX.XX.226:80 {
                address XX.XX.XX.226
            }
        }
        monitor /Common/http 
    }
    ltm pool /Common/Pool_virtual_server_1_8081 {
        members {
            /Common/XX.XX.XX.225:8081 {
                address XX.XX.XX.225
            }
            /Common/XX.XX.XX.226:8081 {
                address XX.XX.XX.226
            }
        }
        monitor /Common/tcp 
    }
    
    
    ltm snatpool /Common/virtual_server_1_snatpool {
        members {
            /Common/XX.XX.42.86
        }
    

    Persitent Profile "ip_origen_3600" consits of source address affinity with an 3600 seconds timeout.

    As you can see, this config is quite straightforward.

    Best regards, Carlos

  • Do you have any SNATs defined separately? (tmsh list /ltm snat)

     

  • Can you check if you have a route present for x.42.86 by any chance? Also where's the default route pointed to? Is the default route pointed back to VRRP address??

     

    -Jinshu

     

  • @crodriguez: no SNAT definitions made separately

     

    @Jinshu, there are no route for x.42.86. VRRP address belongs to a FW connected to our BigIP system. This FW gives L3 connectivity for the servers generating this traffic. If I ping SNAT address I get replies.

     

    I would expect F5 to reply with an ICMP port unreachable to UDP queries on non-listening ports. Even, I would expect F5 to silently drop these packets, but simply putting them back on the network using a L3 route does not make any sense to me.

     

  • @crodriguez: no SNAT definitions made separately

     

    @Jinshu, there are no route for x.42.86. VRRP address belongs to a FW connected to our BigIP system. This FW gives L3 connectivity for the servers generating this traffic. If I ping SNAT address I get replies.

     

    I would expect F5 to reply with an ICMP port unreachable to UDP queries on non-listening ports. Even, I would expect F5 to silently drop these packets, but simply putting them back on the network using a L3 route does not make any sense to me.

     

  • No.. You are defining a pool for SNAT and it will be reachable from the network. It is default behavior of F5 to respond back as it might cause problems if the connection got dropped.

     

    There are situations for recieve the traffic on SNAT pool also (like AFM configuration with single route domain).

     

    Hope this helps.

     

    -Jinshu

     

  • By default, SNATs forward only TCP and UDP traffic. Other IP traffic, such as Internet Control Message Protocol (ICMP), is dropped (You can change it any time). You can configure SNATs to forward any IP packets by modifying the SNAT Packet Forwarding setting.

     

    Check the link below if you want to disable the TCP/UDP protocol forwarding.

     

    Support KB

     

    -Jinshu

     

  • I've got TCP and UDP only on SNAT traffic forwarding. Yes, I'm receiving ICMP reply responses from any SNAT Pool IP configured, but when attempting to contact any TCP or UDP port on these addresses they are getting forwarded.

     ping XX.XX.42.86
    PING XX.XX.42.86 (XX.XX.42.86) 56(84) bytes of data.
    64 bytes from XX.XX.42.86: icmp_req=1 ttl=253 time=11.6 ms
    64 bytes from XX.XX.42.86: icmp_req=2 ttl=253 time=2.13 ms
    64 bytes from XX.XX.42.86: icmp_req=3 ttl=253 time=3.88 ms