<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2015-02-26 06:17, SilverTip257
wrote:<br>
</div>
<blockquote
cite="mid:CA+W-zopD5w=eeEktPhgToKo=A6f+9vrWtEx1S4XM9LNGSOB0Ow@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Feb 25, 2015 at 1:19 PM,
Richard Whittaker <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:richard@avits.ca"
target="_blank">richard@avits.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On
2015-02-25 09:57, SilverTip257 wrote:<br>
<br>
Here's some captures from one of my "near" hosts to one of
the non working "far" hosts...<br>
<br>
</blockquote>
<div><br>
</div>
<div style="">Those packet captures appear to indicate no
problems. Established TCP session and so forth.</div>
</div>
</div>
</div>
</blockquote>
<br>
Here's an SSH session from prometheus to db2. <br>
<br>
root@valiant:~# tcpdump -nn -i eth0.80 host 192.168.64.9<br>
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode<br>
listening on eth0.80, link-type EN10MB (Ethernet), capture size
65535 bytes<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
<br>
Network drawing in finest ASCII form.. <br>
<br>
192.168.0.0/18
192.168.64.0/18<br>
<br>
prometheus (0.2) (Slackware)
illustrious (64.4) (Centos
5.9)<br>
db1 (0.9) (Ubuntu 12.04) valiant (0.1) <>
Public interface <========== Openswan ==============> Public
interface <> remote (64.1) db2 (64.9) (Ubuntu 12.04)<br>
Win (0.5)
Win (64.5) <br>
etc..<br>
<br>
As I mentioned, sessions from 0.2 to 64.4 work. Sessions from 0.2 to
64.9 just hang. <br>
<br>
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. <br>
<br>
<br>
<blockquote
cite="mid:CA+W-zopD5w=eeEktPhgToKo=A6f+9vrWtEx1S4XM9LNGSOB0Ow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">I'd also suggest a list of what host has what
IP address. I don't know what </div>
<div><<a moz-do-not-send="true"
href="http://prometheus.avits.ca">prometheus.avits.ca</a>>
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 <a
moz-do-not-send="true" href="http://192.168.0.0/18">192.168.0.0/18</a>
network.</div>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
<blockquote
cite="mid:CA+W-zopD5w=eeEktPhgToKo=A6f+9vrWtEx1S4XM9LNGSOB0Ow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">While it would be helpful to see your
OpenSwan config for this tunnel, it may not be necessary.
<div style="">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
<a moz-do-not-send="true" href="http://192.168.0.0/18">192.168.0.0/18</a>
network.</div>
</div>
</div>
</div>
</blockquote>
<br>
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). <br>
<br>
<blockquote
cite="mid:CA+W-zopD5w=eeEktPhgToKo=A6f+9vrWtEx1S4XM9LNGSOB0Ow@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div style="">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.</div>
<div style=""><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, I tried MySQL as well. <br>
<br>
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. <br>
<br>
Thanks!<br>
Richard.<br>
<br>
<pre class="moz-signature" cols="72">--
Alberni Valley IT Services
</pre>
</body>
</html>