Forum Discussion

Joe_L_'s avatar
Joe_L_
Icon for Nimbostratus rankNimbostratus
May 13, 2013

Forwarding IP VS not returning packets

Hi all,

 

I apologize for posting what has probably been asked before, but my search-fu seems to be completely failing me at the moment.

 

I'm trying to set up an F5 LTM (11.3) as a gateway for a particular subnet (172.16.88.224/28). The external switch/router has a static route pointing this network to the external address of the F5 cluster (128.6.31.124). The F5, in turn, has a forwarding IP virtual_server setup for the network, allowing all traffic in. (The purpose is to be able to reach hosts on that network directly via SSH or RDP.) However, I cannot get it working right. According to tcpdump, the packets are being received on the internal network interface of the F5, and being passed along to the client. The client responses are coming back to the F5, as expected (the servers all have the proper gateway, 172.16.88.225, setup. However, those return packets are *NOT* making it back through the F5 (ie. from the internal interface to the external interface). I'm assuming I have something configured wrong somewhere, but I can't see what.

 

I've attached stripped-down versions of bigip.conf and bigip_base.conf with the relevant network and virtual sever information.

 

If anyone can help me, I'd really appreciate it; I've been fighting this for several days, and haven't found any documentation, advice, or forum posts that address precisely my problem.

 

 

Thanks.

 

config
design

4 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    May 13, 2013
    Sorry but can you point out which VS, RD etc. relates to your issue please?

     

     

    Sounds like either a plain routing issue or asymmetric routing is occurring perhaps.
  • Joe_L_'s avatar
    Joe_L_
    Icon for Nimbostratus rankNimbostratus
    May 13, 2013
    The External interface is 128.6.31.124, which is the floating traffic-group IP between the active-passive failover F5 pair. The internal network is 172.16.88.224/28, on VLAN "Adobe_Connect". The F5 floating IP on that interface is 172.16.88.225, which is also set to the primary gateway address on all servers attached to that network. The default route for the F5 traffic (non-management) is 128.6.31.65, located on the External net.

     

     

    The forwarding VS is "Adobe-Connect_Net", defined as follows:

     

     

    ltm virtual /Common/Adobe-Connect_Net {

     

    description 172.16.88.224/28

     

    destination /Common/172.16.88.224:0

     

    ip-forward

     

    mask 255.255.255.240

     

    profiles {

     

    /Common/AC_Net_fastL4 { }

     

    }

     

    source 0.0.0.0/0

     

    translate-address disabled

     

    translate-port disabled

     

    vlans-disabled

     

    }

     

     

    ltm profile fastl4 /Common/AC_Net_fastL4 {

     

    app-service none

     

    defaults-from /Common/fastL4

     

    idle-timeout 300

     

    ip-tos-to-client pass-through

     

    ip-tos-to-server pass-through

     

    keep-alive-interval disabled

     

    link-qos-to-client pass-through

     

    link-qos-to-server pass-through

     

    loose-close enabled

     

    loose-initialization enabled

     

    mss-override 0

     

    reassemble-fragments disabled

     

    reset-on-timeout enabled

     

    rtt-from-client disabled

     

    rtt-from-server disabled

     

    software-syn-cookie disabled

     

    tcp-close-timeout 5

     

    tcp-generate-isn disabled

     

    tcp-handshake-timeout 5

     

    tcp-strip-sack disabled

     

    tcp-timestamp-mode preserve

     

    tcp-wscale-mode preserve

     

    }

     

     

     

    To clarify what I said in the prevoius message, packets (ping, SSH, etc) are arriving at the External interface of the F5, and being properly passed to the Adobe_Connect internal interface. Reply packets from the servers on that network, however, are *NOT* being passed back the other way. (ie. The Adobe_Connect interface sees the packets, but according to tcpdump, they aren't being passed back to the External interface.)

     

  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    May 13, 2013
    OK, I see the issue, the VS on the internal network needs to be 0.0.0.0:0, not 172.16.88.224:0. Remember the VS is the destination, not the source.
  • Joe_L_'s avatar
    Joe_L_
    Icon for Nimbostratus rankNimbostratus
    May 13, 2013
    Posted By What Lies Beneath on 05/13/2013 11:28 AM

     

    OK, I see the issue, the VS on the internal network needs to be 0.0.0.0:0, not 172.16.88.224:0. Remember the VS is the destination, not the source.

     

    Unfortunately, that doesn't seem to work either. The result is the same.

     

    As an additional datapoint, here's what it looks like if I try to ping or SSH from my workstation to a server behind the F5:

     

     

    [user@f5lb-1:Active] ~ tcpdump -i Adobe_Connect -n host 128.6.210.75

     

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

     

    listening on Adobe_Connect, link-type EN10MB (Ethernet), capture size 96 bytes

     

    14:38:03.654655 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 0, length 64

     

    14:38:04.655426 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 1, length 64

     

    14:38:05.656156 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 2, length 64

     

    14:38:06.657307 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 3, length 64

     

    14:38:07.658310 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 4, length 64

     

    14:38:08.659407 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 5, length 64

     

    14:38:09.660519 IP 172.16.88.227 > 128.6.210.75: ICMP echo reply, id 52897, seq 6, length 64

     

    14:38:14.462946 IP 172.16.88.227.ssh > 128.6.210.75.49178: R 0:0(0) ack 3909000084 win 0

     

    14:38:15.468394 IP 172.16.88.227.ssh > 128.6.210.75.49178: R 0:0(0) ack 1 win 0

     

    14:38:16.573520 IP 172.16.88.227.ssh > 128.6.210.75.49178: R 0:0(0) ack 1 win 0

     

    14:38:17.674576 IP 172.16.88.227.ssh > 128.6.210.75.49178: R 0:0(0) ack 1 win 0

     

    14:38:18.777940 IP 172.16.88.227.ssh > 128.6.210.75.49178: R 0:0(0) ack 1 win 0

     

    14:38:19.885833 IP 172.16.88.227.ssh > 128.6.210.75.49178: R 0:0(0) ack 1 win 0

     

    ^C

     

    13 packets captured

     

    13 packets received by filter

     

    0 packets dropped by kernel

     

     

    So, obviously, the server is receiving the initial packets and trying to respond. The External interface, however, shows nothing being sent out; neither does the switch it is connected to, for that matter. Just for testing, I also setup packet filtering rules; the logs indicate that packets in both directions (from my workstation to the server, and vice-versa) are being accepted, not dropped. So there's something between the transition from Adobe_Connect to External that's getting dropped somewhere, it appears. Do I need to add a specific route or something similar to that network, to direct it out the External interface?