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

Thu Feb 26 12:22:07 EST 2015

On 2015-02-26 06:17, SilverTip257 wrote:
>
> On Wed, Feb 25, 2015 at 1:19 PM, Richard Whittaker <richard at avits.ca 
> <mailto:richard at avits.ca>> wrote:
>
>     On 2015-02-25 09:57, SilverTip257 wrote:
>
>     Here's some captures from one of my "near" hosts to one of the non
>     working "far" hosts...
>
>
> Those packet captures appear to indicate no problems.  Established TCP 
> session and so forth.

Here's an SSH session from prometheus to db2.

root at valiant:~# tcpdump -nn -i eth0.80 host 192.168.64.9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.80, link-type EN10MB (Ethernet), capture size 65535 bytes
09:01:38.404066 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [S], seq 
3910239940, win 14600, options [mss 1460,sackOK,TS val 420418025 ecr 
0,nop,wscale 7], length 0
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
09:01:38.424215 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [.], ack 
1, win 115, options [nop,nop,TS val 420418030 ecr 643340463], length 0
09:01:38.452535 IP 192.168.64.9.22 > 192.168.0.2.50220: Flags [P.], seq 
1:42, ack 1, win 1560, options [nop,nop,TS val 643340470 ecr 420418030], 
length 41
09:01:38.452675 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [.], ack 
42, win 115, options [nop,nop,TS val 420418038 ecr 643340470], length 0
09:01:38.452747 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [P.], seq 
1:21, ack 42, win 115, options [nop,nop,TS val 420418038 ecr 643340470], 
length 20
09:01:38.452945 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [.], seq 
21:479, ack 42, win 115, options [nop,nop,TS val 420418038 ecr 
643340470], length 458
09:01:38.470314 IP 192.168.64.9.22 > 192.168.0.2.50220: Flags [.], ack 
21, win 1560, options [nop,nop,TS val 643340475 ecr 420418038], length 0
09:01:38.470369 IP 192.168.64.9.22 > 192.168.0.2.50220: Flags [.], ack 
479, win 1685, options [nop,nop,TS val 643340475 ecr 420418038], length 0
09:01:38.470450 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [P.], seq 
479:773, ack 42, win 115, options [nop,nop,TS val 420418042 ecr 
643340475], length 294
09:01:38.522121 IP 192.168.64.9.22 > 192.168.0.2.50220: Flags [.], ack 
773, win 1810, options [nop,nop,TS val 643340488 ecr 420418042], length 0
09:03:38.449574 IP 192.168.64.9.22 > 192.168.0.2.50220: Flags [F.], seq 
1026, ack 773, win 1810, options [nop,nop,TS val 643370470 ecr 
420418042], length 0
09:03:38.449690 IP 192.168.0.2.50220 > 192.168.64.9.22: Flags [.], ack 
42, win 115, options [nop,nop,TS val 420448037 ecr 
643340475,nop,nop,sack 1 {1026:1027}], length 0

Network drawing in finest ASCII form..

192.168.0.0/18                                                 
192.168.64.0/18

prometheus (0.2)   (Slackware)                                         
illustrious (64.4) (Centos 5.9)
db1 (0.9) (Ubuntu 12.04)                 valiant (0.1) <> Public 
interface <========== Openswan ==============> Public interface <> 
remote (64.1)          db2 (64.9) (Ubuntu 12.04)
Win (0.5)                                                        Win (64.5)
etc..

As I mentioned, sessions from 0.2 to 64.4 work. Sessions from 0.2 to 
64.9 just hang.

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. This got me to thinking the issue might be fragmentation, 
but large pings work just fine.

> I'd also suggest a list of what host has what IP address.  I don't 
> know what
> <prometheus.avits.ca <http://prometheus.avits.ca>> address is or which 
> it should be using (across the tunnel I'd expect RFC1918 like your 
> other hosts).  I'm resolving prometheus' hostname to a public which 
> isn't in that 192.168.0.0/18 <http://192.168.0.0/18> network.

I have a wildcard on my domain name for anything not expicitly defined. 
That's likely what you're running into. All of my internal hosts are 
resolved on a private DNS setup.

> While it would be helpful to see your OpenSwan config for this tunnel, 
> it may not be necessary.
> I expect db2 is trying to connect to prometheus' public IP address.  
> Try excluding DNS from the equation by pinging from db2 to prometheus' 
> address in the 192.168.0.0/18 <http://192.168.0.0/18> network.

Prometheus doesn't have a public address. The packet capture above, and 
the ones previously were taken on the gateway server (0.1) on the 
internal interface (eth0.80).

>
> Since you're using SSH to remotely control those systems, you might 
> use some other protocol/port to troubleshoot.  You said TCP doesn't 
> work across the tunnel from <prometheus> to <db2>.  If there isn't 
> some other TCP application, you might use netcat to do tests in either 
> direction and this will allow you to filter your packet capture to 
> that traffic easily.
>

Yes, I tried MySQL as well.

I have also tried NFS over UDP from 0.9 to 64.9, and it was successful 
in transferring a 900KB file from one host to the other. This is what 
got me to thinking there might be some TCP option in the Ubuntu 12.04 
server that I have been missing.

Thanks!
Richard.

-- 
Alberni Valley IT Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150226/c4d65978/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: richard.vcf
Type: text/x-vcard
Size: 277 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20150226/c4d65978/attachment.vcf>