From: Corey Rogers (corey_at_wamcodm.com)
Date: Wed Jul 31 2002 - 23:44:09 CEST
This is really strange. I have got the FreeSWAN tunnelling to one of our
clients from a test machine. Both machines are using FreeSWAN and
GNU/Linux. Using eth0 on our box I can initiate the tunnel without
problems. On eth1 I cannot and all the errata points to routing issues
which shouldn't be the case.
Both interfaces have gateways with access to the client test box. The
client boxes are pingable from either interface (this includes aliases
which are on the same subnets as their main interface) and traceroutes
show the packets pass through their respective gateway machines.
I know it is not a problem with aliases because the client machine is
also setup and working correctly with its alias. As is the common
responce it seems to be a routing issue but is it my error or FreeSWANs?
If the error is mine, please point it out.
LEGEND:
Local ipsec gateway address is 10.XXX.XXX.253 (eth1:1)
remote ipsec gateway address is 10.YYY.YYY.250 (eth0:1)
"ipsec look" shows the ipsec route on the gateway in the order below.
10.XXX.XXX.0 0.0.0.0 255.255.255.0 ipsec0
10.YYY.YYY.250 10.XXX.XXX.254 255.255.255.255 "UGH" ipsec0
On the working client machine this is the result of the same command.
10.XXX.XXX.253 10.YYY.YYY.254 255.255.255.255 "UGH" ipsec0
10.YYY.YYY.0 0.0.0.0 255.255.255.0 ipsec0
In all my successful tests the ipsec look command shows the default
gateway for the tunnel listed first. Is there a solution to this and why
does it occur?
This is reproducible and when manually bringing up the interface (even
though using auto keys) with the commands below (assuming the service
isn't started). I have also purposely removed the "auto=start" to aid in
troubleshooting.
#/etc/rc.d/init.d/ipsec start
#ipsec auto --add connection
#ipsec auto --route connection
(The routes are entered in incorrect order shown by doing an ipsec look)
#ipsec auto --up connection
As expected the connection fails.
Any idea why this occurs would be appreciated (please no vague answers
like "routing"). I've gone over the routing a million times and packets
are not blocked, NATTED or dropped. tcpdumps have shown queries are
appearing on both machines but the tunnel refuses to come up on our end.
Here is a look at the ipsec.conf file.
config setup
#interfaces=%defaultroute
interfaces="ipsec0=eth1:0"
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
conn %default
type=tunnel
keyingtries=0
keylife=3h
disablearrivalcheck=no
authby=secret
#auto=start
right=%any
keyexchange=ike
auth=esp
conn connection
left=10.XXX.XXX.253
#leftsubnet=
leftnexthop=10.XXX.XXX.254
right=10.YYY.YYY.250
#rightsubnet=
rightnexthop=10.YYY.YYY.254
Like I said, it works when used with eth0 in the same box here in the
office. Admittedly the paths are different but that does not explain the
routing error. Any help would be appreciated. Thanks to all in advance
and to the developers for a great program. Excellent work.
Corey Rogers
-- Corey Rogers Junior System Administrator Wamco Technology Group Ltd (Barbados) #3 Mahogany Court, Wildey, St. Michael Phone: (246)437-3154 FAX: (246)228-4319"If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein
_______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.4 : Mon Aug 05 2002 - 21:01:35 CEST