On Thu, 22 Mar 2007 05:30:45 -0600, Jacob Yocom-Piatt wrote:
RW wrote:
I have a simple setup.
Sydney to Melbourne and the ipsec.conf is one of the nice easy ones
whilst I learn to do more complex setups. It has been working for
months.
Today doing ipsecctl -s all at either end generates the expected
output. Each is a mirror of the other.
netstat -rnf encap shows expected output at both ends. Again mirrors of
the other.
However sshing into each and doing a traceroute to t'other end gives
madly assymetric results.
With the distant gateway as the target Syd gets to Mel in one hop, as
expected.
Mel gets to Syd going out the $ext_if rather than the encap. As the
LANs are RFC1918s Mel cannot get to Syd but Syd can get to Mel.
i wouldn't expect you to have a route not set on the isakmpd endpoints,
but i have a route add remote net internal private IP in the
hostname.if files for the internal interfaces on both endpoints. that's
the only thing i can think of that would work for a while (manually
added routes) and then stop working after, say, a reboot of one endpoint.
No, not the problem here. It works without any extra route lines, but
read the update at the bottom of the quoted stuff.
cheers,
jake
Killing (desperation set in) isakmpd and restarting both ends did
nothing to change the situation.
What kind of diagnostics can I use to debug this? Extra points for a
correct guess as to the cause all this time after installation.
Thanks,
OK, a night's sleep led to an early morning Eureka moment.
I should have said What changed? and I did. The mistake that dummy me
made was not to consider a change made ages ago. That change did not
break ipsec for the clients but did for the firewall endpoint at one
end.
For the benefit of others here is the detail:
Originally Mel (bourne) was on an ADSL connection running half-bridge
so the OpenBSD firewall had the WAN IP on $ext_if and the first
(usable) of a /29 on the server LAN NIC.
Due to problems with the modem we swapped it out for one that does not
do half-bridge.
So I gave $ext_if 192.168 addr to mate with the one on the modem. I
then did all the NAT stuff based on $svrlan_if
e.g.
nat on $ext_if from $fwext to any - $svr_if
nat on $ext_if from $lan_ip to any - $svr_if
where fwext is the IP on $ext_if and lan_ip is the /24 for the LAN
users.
So all outbound packets look like they come from the svr_lan nic.
That works sweetly and I have a similar setup at home. Neither of those
has the /30 that would be preferred to make everything work but that's
IP scarcity for you.
So ipsec works just fine for everything on Mel and its mate, Syd.
Except for packets I generated at Mel using ssh login. Until I woke up
and used the -I flag in ping and the -s flag in traceroute to source
the packets from the svrlan_if address, that is.
I don't know what, if anything, can be done to ensure that packets
generated in the firewall Mel can be forced to use the tunnel when the
destination is Syd, but it isn't a showstopper (fingers crossed!)
So, there was a change ages ago and I had never after it, until now,
tried to ping up the tunnel from the firewall so I didn't know that it
was kinda broken, and if anybody knows how to unbreak it I'll be
pleased just in case
Thanks Jacob for your reply.
Rod/
From the land down under: Australia.
Do we look umop apisdn from up over?
