Forum Discussion

dmoon57_23603's avatar
dmoon57_23603
Icon for Nimbostratus rankNimbostratus
Nov 04, 2008

is snat the solution?

here's my situation:

I have two servers that have two apps listening on separate ports (one listening on 8080, the other on 8081). The server's default gateway is not the LTM. On the LTM, I have two pools and two vips set up using the same servers, just on different ports:

  
  pool APP1_POOL {  
     monitor all gateway_icmp  
     members  
        10.100.70.199:8080  
        10.100.70.201:8080  
  }  
  pool APP2_POOL {  
     monitor all gateway_icmp  
     members  
        10.100.70.199:8081  
        10.100.70.201:8081  
  }  
  virtual APP1_VIP {  
     pool APP1_POOL  
     destination 10.100.59.130:http  
     ip protocol tcp  
     profiles  
        oneconnect  
        tcp  
     persist app1_cookie  
  }  
  virtual APP2_VIP {  
     pool APP2_POOL  
     destination 10.100.59.131:8081  
     ip protocol tcp  
     profiles  
        oneconnect  
        tcp  
     persist app2_cookie  
  }  
  

The 8081 app makes a call to the vip: http://10.100.59.131:8081. I thought a simple snat would do the trick but it doesn't seem to work, my connection hangs:

  
  snat mysnat_snat {  
     translation 10.100.59.131  
     origins  
          10.100.70.199  
          10.100.70.201  
  }  
  

any ideas?

5 Replies

  • Didn't work. The weird thing is, I have a very similar setup working on different LTM.
  • I can't see why it wouldn't be working with your original configuration or SNAT automap. Can you capture a tcpdump of the issue? You can search on AskF5 for tcpdump or SOL411 for info on using tcpdump.

     

     

    Aaron
  • this is with a filter for port 8081 listening on the special f5 interface 0.0

     

     

    tcpdump: listening on 0.0

     

    11:26:46.095783 802.1Q vlan61 P0 10.100.70.201.54403 > 10.100.59.131.8081: S 301215954:301215954(0) win 5840 (DF)

     

    11:26:46.095802 802.1Q vlan61 P0 10.100.59.131.8081 > 10.100.70.201.54403: S 1495450002:1495450002(0) ack 301215955 win 4380 (DF)

     

    11:26:46.096034 802.1Q vlan61 P0 10.100.70.201.54403 > 10.100.59.131.8081: . ack 1 win 1460 (DF)

     

    11:26:46.096252 802.1Q vlan61 P0 10.100.1.131.54403 > 10.100.70.199.8081: S 3351293012:3351293012(0) win 4380 (DF)

     

    11:26:46.096317 802.1Q vlan61 P0 10.100.70.201.54403 > 10.100.59.131.8081: P 1:140(139) ack 1 win 1460 (DF)

     

    11:26:46.195878 802.1Q vlan61 P0 10.100.59.131.8081 > 10.100.70.201.54403: . ack 140 win 4519 (DF)

     

    11:26:47.096001 802.1Q vlan61 P0 10.100.1.131.54403 > 10.100.70.199.8081: S 3351293012:3351293012(0) win 4380 (DF)

     

    11:26:48.296162 802.1Q vlan61 P0 10.100.1.131.54403 > 10.100.70.199.8081: S 3351293012:3351293012(0) win 4380 (DF)

     

    11:26:49.496319 802.1Q vlan61 P0 10.100.1.131.54403 > 10.100.70.199.8081: S 3351293012:3351293012(0) win 4380 (DF)

     

    11:26:50.695996 802.1Q vlan61 P0 10.100.59.131.8081 > 10.100.70.201.54403: R 1:1(0) ack 140 win 4519 (DF)

     

    11:26:51.698644 802.1Q vlan61 P0 10.100.70.201.54408 > 10.100.59.131.8081: S 3410045593:3410045593(0) win 5840 (DF)

     

    11:26:51.698663 802.1Q vlan61 P0 10.100.59.131.8081 > 10.100.70.201.54408: S 2248651759:2248651759(0) ack 3410045594 win 4380 (DF)

     

    11:26:51.699132 802.1Q vlan61 P0 10.100.70.201.54408 > 10.100.59.131.8081: . ack 1 win 1460 (DF)

     

    11:26:51.699335 802.1Q vlan61 P0 10.100.1.131.54408 > 10.100.70.199.8081: S 3433908610:3433908610(0) win 4380 (DF)

     

    11:26:51.699341 802.1Q vlan61 P0 10.100.70.201.54408 > 10.100.59.131.8081: P 1:140(139) ack 1 win 1460 (DF)

     

    11:26:51.798994 802.1Q vlan61 P0 10.100.59.131.8081 > 10.100.70.201.54408: . ack 140 win 4519 (DF)
  • Here is a simplified version of the trace:

     

     

     

    11:26:46.095783 - Client:54403 > VIP:8081: SYN

     

    11:26:46.095802 - VIP:8081 > Client:54403: SYN ACK

     

    11:26:46.096034 - Client:54403 > VIP:8081: . ACK

     

    11:26:46.096252 - SNAT:54403 > Node:8081: SYN

     

    11:26:46.096317 - Client:54403 > VIP:8081: PSH ACK

     

    11:26:46.195878 - VIP:8081 > Client:54403: . ACK

     

    11:26:47.096001 - SNAT:54403 > Node:8081: SYN

     

    11:26:48.296162 - SNAT:54403 > Node:8081: SYN

     

    11:26:49.496319 - SNAT:54403 > Node:8081: SYN

     

    11:26:50.695996 - VIP:8081 > Client:54403: R ACK

     

     

    11:26:51.698644 - Client.54408 > VIP:8081: SYN

     

    11:26:51.698663 - VIP:8081 > Client.54408: SYN ACK

     

    11:26:51.699132 - Client.54408 > VIP:8081: . ACK

     

    11:26:51.699335 - SNAT:54408 > Node:8081: SYN

     

    11:26:51.699341 - Client.54408 > VIP:8081: PSH ACK

     

    11:26:51.798994 - VIP:8081 > Client.54408: . ACK

     

     

     

     

    You can see that the node never responds to the SNAT address to estabblish a TCP connection. If you capture a trace on the node, do you see the response going out a different interface?

     

     

    If you try the same test with SNAT automap, LTM should use a self IP on the node's subnet and the response should be sent back to LTM on the same interface the node received the request on. I'm surprised that SNAT automap wouldn't work here.

     

     

    Aaron