Hello group, I have an IPIP tunnel from host A to host B, where I send an IP request thru (setup is attached in the image)
once the request goes thru a tunnel (to host B), I route it to a 2nd network interface on B (need to do this for market data using Solarflare network interface) everything is working fine up until the point where the IP is sent out from the p1p1 interface (Solarflare), the reason being that the source IP remains the IP of the tunnel interface and not host B, ie, 1. I netcat to an customer IP and port from Host A [16:17 root@hostA ]# nc 207.17.44.102 41811 -vvv 2. this request goes thru IPIP tunnel to host B, I can see it coming in over host A tunnel virtual interface (192.168.2.1) root@hostB /h/s/scripts# tcpdump -i *tunnel-a* tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tunlchice2, link-type RAW (Raw IP), capture size 262144 bytes 15:44:34.355274 IP *192.168.2.1*.37718 > 207.17.44.102.41811: Flags [S], seq 1362393834, win 14400, options [mss 1440,sackOK,TS val 2703661307 ecr 0, nop,wscale 10], length 0 15:44:35.318864 IP *192.168.2.1*.34440 > 10.3.4.65.48854: Flags [S], seq 1953463356, win 14400, options [mss 1440,sackOK,TS val 2703662270 ecr 0,nop,wscale 10], length 0 15:44:35.355837 IP 192.168.2.1.37718 > 207.17.44.102.41811: Flags [S], seq 1362393834, win 14400, options [mss 1440,sackOK,TS val 2703662307 ecr 0,nop,wscale 10], length 0 3. on Host B, I have a route that routes this IP to the Solarflare interface (p1p1) root@hostB /h/s/scripts# route -n | grep 207.17.44.102 207.17.44.102 192.168.38.17 255.255.255.255 UGH 100 0 0 p1p1 4. when I do a TCP dump on this Solarflare interface, I see the request coming in from Tunnel IP, and its timing out because the destination (customer) doesnt recognize this IP, the connection would be accepted only if the customer sees "host B" IP as the source, root@hostB /e/s/network-scripts# tcpdump -i *p1p1* | grep 207.17.44.102 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on p1p1, link-type EN10MB (Ethernet), capture size 262144 bytes 15:50:43.952288 IP *192.168.2.1*.45738 > 207.17.44.102.41811: Flags [S], seq 90831757, win 14400, options [mss 1440,sackOK,TS val 2704030904 ecr 0, nop,wscale 10], length 0 15:50:44.952854 IP *192.168.2.1*.45738 > 207.17.44.102.41811: Flags [S], seq 90831757, win 14400, options [mss 1440,sackOK,TS val 2704031904 ecr 0, nop,wscale 10], length 0 My question is, what OS setting is controlling a sticky IP for each session? On our other servers, when the IP gets routed from Tunnel to Solarflare interface, its IP changes to become the same as the host, for example, this is on another pair of working servers, root@qbtfr1 /etc# tcpdump -i p1p1 | grep 129.133 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on p1p1, link-type EN10MB (Ethernet), capture size 262144 bytes 22:53:05.148215 IP *qbtfr1*.40320 > 192.195.129.133.micromuse-ncpw: Flags [S ], seq 2994687068, win 14400, options [mss 1440,sackOK,TS val 4089830767 ecr 0,nop,wscale 10], length 0 It sees the source hostname as itself, not the IP of the tunnel. something is preventing the packet from chaning its source IP when its routed. Just wondering if anyone has an idea whats doing this. thanks! -- -- You received this message because you are subscribed to the Linux Users Group. To post a message, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit our group at http://groups.google.com/group/linuxusersgroup References can be found at: http://goo.gl/anqri Please remember to abide by our list rules (http://tinyurl.com/LUG-Rules) --- You received this message because you are subscribed to the Google Groups "Linux Users Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
