[Openswan Users] Tunnel up, some hosts work, others don't.

Fri Feb 27 14:11:14 EST 2015

On 02/26/2015 06:03 PM, Richard Whittaker wrote:
> On 2015-02-26 10:41, Simon Deziel wrote:
>> On 02/26/2015 01:38 PM, Richard Whittaker wrote:
>>> On 2015-02-26 09:31, Simon Deziel wrote:
>>>> On 02/26/2015 12:22 PM, Richard Whittaker wrote:
>>>>> I can also reproduce this with MySQL. I can establish an initial
>>>>> connection and login to db2 from either 0.2 or 0.9, but as soon as
>>>>> I try
>>>>> "connect mysql" from the client command line, everything just
>>>>> freezes in
>>>>> the client.
>>>>
> 
> Here's another SSH session seen from both ends of the connection. The
> timeframe is identical, and I eventually Contol-Ced the connection.
> 
> The session seen from db2 (192.168.64.9)
> root at db2:~# tcpdump -i eth0 -nn host 192.168.0.2
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 15:00:21.027467 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [S], seq
> 3882435085, win 14600, options [mss 1200,sackOK,TS val 425798676 ecr
> 0,nop,wscale 7], length 0

Those MSS values are better than they were from a previous capture of yours:

09:01:38.424093 IP 192.168.64.9.22 > 192.168.0.2.50220: Flags [S.], seq
1507369155, ack 3910239941, win 12480, options [mss 470,sackOK,TS val
643340463 ecr 420418025,nop,wscale 3], length 0

A MSS of 470 was probably not even valid; at least the smallest MSS
allowed for IPv4 is 536.

> 15:00:21.027529 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [S.], seq
> 1449523050, ack 3882435086, win 12480, options [mss 1260,sackOK,TS val
> 648721399 ecr 425798676,nop,wscale 3], length 0
> 15:00:21.042506 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [.], ack
> 1, win 115, options [nop,nop,TS val 425798680 ecr 648721399], length 0
> 15:00:21.056680 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [P.], seq
> 1:42, ack 1, win 1560, options [nop,nop,TS val 648721406 ecr 425798680],
> length 41
> 15:00:21.077272 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [.], ack
> 42, win 115, options [nop,nop,TS val 425798688 ecr 648721406], length 0
> 15:00:21.077315 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [P.], seq
> 1:21, ack 42, win 115, options [nop,nop,TS val 425798688 ecr 648721406],
> length 20
> 15:00:21.077862 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], ack
> 21, win 1560, options [nop,nop,TS val 648721411 ecr 425798688], length 0
> 15:00:21.080722 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 21, win 1560, options [nop,nop,TS val 648721412 ecr
> 425798688], length 500
> 15:00:21.081453 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [P.], seq
> 542:1026, ack 21, win 1560, options [nop,nop,TS val 648721412 ecr
> 425798688], length 484
> 15:00:21.096487 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [P.], seq
> 21:773, ack 42, win 115, options [nop,nop,TS val 425798693 ecr
> 648721411], length 752
> 15:00:21.134915 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], ack
> 773, win 1748, options [nop,nop,TS val 648721426 ecr 425798693], length 0
> 15:00:21.290857 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648721465 ecr
> 425798693], length 500
> 15:00:21.714844 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648721571 ecr
> 425798693], length 500
> 15:00:22.562862 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648721783 ecr
> 425798693], length 500
> 15:00:24.262843 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648722208 ecr
> 425798693], length 500
> 15:00:27.662861 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648723058 ecr
> 425798693], length 500
> 15:00:34.470859 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648724760 ecr
> 425798693], length 500
> 15:00:48.070885 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648728160 ecr
> 425798693], length 500
> 15:01:15.270876 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [.], seq
> 42:542, ack 773, win 1748, options [nop,nop,TS val 648734960 ecr
> 425798693], length 500
> 15:01:33.623333 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [F.], seq
> 773, ack 42, win 115, options [nop,nop,TS val 425816823 ecr 648721411],
> length 0
> 15:01:33.624976 IP 192.168.64.9.22 > 192.168.0.2.36698: Flags [F.], seq
> 1026, ack 774, win 1748, options [nop,nop,TS val 648739548 ecr
> 425816823], length 0
> 15:01:33.645061 IP 192.168.0.2.36698 > 192.168.64.9.22: Flags [R], seq
> 3882435859, win 0, length 0
> ^C
> 22 packets captured
> 25 packets received by filter
> 0 packets dropped by kernel
> root at db2:~#
> 
> ---
> The session seen from Prometheus (192.168.0.2).
> 
> root at prometheus:~# tcpdump -i eth3.80 -nn host 192.168.64.9
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth3.80, link-type EN10MB (Ethernet), capture size 96 bytes
> 15:00:21.008800 IP 192.168.0.2.36698 > 192.168.64.9.22: S
> 3882435085:3882435085(0) win 14600 <mss 1460,sackOK,timestamp 425798676
> 0,nop,wscale 7>
> 15:00:21.025204 IP 192.168.64.9.22 > 192.168.0.2.36698: S
> 1449523050:1449523050(0) ack 3882435086 win 12480 <mss
> 1200,sackOK,timestamp 648721399 425798676,nop,wscale 3>

Now why is this side of the tunnel doesn't see the same MSS values? It
looks like your source/destination IP criteria for the MSS mangling on
the gateways could be at fault.

Can you try to clamp the MSS to PMTU on all communication crossing the 2
gateways? I'd expect this to result in the same MSS values to be
observed on both ends of the tunnel.

Simon