Frees/wan setup problems
Cole Tuininga
colet at code-energy.com
Wed Feb 26 15:03:37 EST 2003
On Wed, 2003-02-26 at 13:01, Kenneth E. Lussier wrote:
> On Wed, 2003-02-26 at 11:45, Cole Tuininga wrote:
>
> >
> > Traceroute from the gateways give me nothing.
>
> Well that *IS* interesting. If the gateways can't talk to each other,
> then nothing behind them can.
Well, they can talk to each other via regular (non VPN'd) tcp/ip:
>From 209.187.117.100:
# traceroute -n 63.127.199.26
traceroute to 63.127.199.26 (63.127.199.26), 30 hops max, 38 byte
packets
1 209.187.117.65 11.780 ms 1.521 ms 1.544 ms
2 209.187.117.241 2.671 ms 2.701 ms 2.717 ms
3 209.187.117.245 2.569 ms 2.497 ms 2.498 ms
4 199.105.112.2 9.430 ms 11.276 ms 3.308 ms
5 207.3.150.34 10.762 ms 5.452 ms 5.460 ms
6 10.10.10.1 6.295 ms 5.918 ms 9.343 ms
7 207.3.144.222 46.684 ms 48.133 ms 42.985 ms
8 63.127.199.26 46.510 ms 45.794 ms 43.115 ms
But not via the VPN:
traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 38 byte packets
1 * * *
(etc)
> Try this.... Create multiple conn sections
> for each of these:
> 4) 192.168.1.0/24-to-192.168.2.0/24
This is what I put in place originally - yes?
> 1) Gateway-to-gateway
This is the one that crashed my ability to connect from an internal
machine to the external ip of a gateway - right?
> 2) 192.168.1.0/24-to-opposite gateway
> 3) 192.168.2.0/24-to-opposite gateway
You're basically saying to just add these two in? Will it take care of
the problem I mention above?
> > From a host on the inside
> > of my home network (the 192.168.2.x side), I get:
> >
> > root at colap:~# traceroute -n 192.168.1.68
> > traceroute to 192.168.1.68 (192.168.1.68), 30 hops max, 38 byte packets
> > 1 192.168.2.1 0.384 ms 0.508 ms 0.388 ms
> > 2 * * *
> > 3 * * *
> > etc, etc.
>
> Again, this is fairly interesting. 192.168.2.1 doesn't know what to do
> with the traffic. Either that, or ICMP is being blocked.
I don't think ICMP is being blocked. When I had the tunnel working
before, I could ping through without trouble.
Just so we make sure we're on the same wavelength, here's my iptables
setup:
On both systems, the regular tables (INPUT/FORWARD/OUTPUT) have no rules
and a default policy of accept.
Home gateway:
# iptables -nL -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 0.0.0.0/0 !192.168.0.0/16
to:63.127.199.26
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Work gateway:
# iptables -nL -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 0.0.0.0/0 !192.168.0.0/16
to:209.187.117.100
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
> You can try
> forcing a route between the two gateways, which might help. Can you send
> me the output of a pluto barf? (BTW... Who *NAMES* these things??? ;-)
A barf from when? Startup? When I try to send ICMP packets through?
TCP packets?
> Sorry about that. See above where I suggest the other tunnels. My
> thinking was a bit off on that, and basically what I told you to do was
> send all traffic between the two through the ipsec tunnel, which will
> sort of stop all other traffic. My bad ;-)
*grin*
> Yeah, I know... I had to shut down a system that has an uptime of 364
> days. It was painfull, but I did it anyway ;-)
We've had a couple systems running 2.2 kernels roll on the uptime
recently. Anybody happen to know what the rollover point is? Seems to
be somewhere in the vicinity of about 400 days.
> Nothing especially out of the ordiary, except maybe that you have two
> routes for the destination of 63.127.199.24, one using eth0 and one
> using ipsec0. both with the same metric. But then again, that could be
> my fault ;-)
I don't think so - I removed the connection you mentioned before and
both routes are still there. Now it looks like:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
63.127.199.24 0.0.0.0 255.255.255.252 U 0 0 0
eth0
63.127.199.24 0.0.0.0 255.255.255.252 U 0 0 0
ipsec0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
192.168.1.0 63.127.199.25 255.255.255.0 UG 0 0 0
ipsec0
0.0.0.0 63.127.199.25 0.0.0.0 UG 0 0 0
eth0
When I stop ipsec, the table looks like this:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
63.127.199.24 0.0.0.0 255.255.255.252 U 0 0 0
eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
0.0.0.0 63.127.199.25 0.0.0.0 UG 0 0 0
eth0
> Run tcpdump -i eth0 and see if the packets are making out of the
> interface.
ping performed from 192.168.1.68 to 192.168.2.1
tcpdump -i eth0 (internal interface) done on 192.168.1.1
Here's the relevant packets:
14:40:51.681903 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
14:40:52.672484 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
14:40:53.672336 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
14:40:54.672210 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
pinging to an internal ip on my home network (192.168.2.69) yielded
similar results.
> > Did I give all necessary info?
>
> So far, so good... Like I said earlier, if you could sent me a full
> pluto barf, that would help (it will be quite long, too). Also, if you
> kill the connection and start it up again, the output of the connection
> starting from both syslogs would help.
How big is this going to be? Would it be more appropriate to send off
list or is it ok to send it on list?
--
"Lottery: A tax on people who are bad at math."
Cole Tuininga
Lead Developer
Code Energy, Inc
colet at code-energy.com
PGP Key ID: 0x43E5755D
More information about the gnhlug-discuss
mailing list