[ sorry for cross-posting this to newbies and users, but I''m a bit
desperate to get this resolved ]
This is strange... I had this working before without any problems, and
recently we started to have some odd issues. I can''t be sure exactly
what has changed as I''m unfortunately not the only person with access
to the server. {sigh}
The problem is that I pretty much set up IPSec from the docs and it had
been working fine. This may possibly be an IPSec issue and not a
Shorewall issue, but I know it was updated to 1.4.9 around the time
weird things started, so any pointers would be appreciated.
If I connect via IPSec from a machine behind a router on the remote
end, all is fine:
192.168.42.242/32 == 12.221.192.13 -- 208.10.57.129 == 192.168.168.0/24
However, if I connect from a direct endpoint on the net like this:
12.221.194.89 -- 208.10.57.129 == 192.168.168.0/24
I get martian errors:
Feb 25 20:09:04 fw kernel: martian source 208.10.57.129 from
12.221.194.89, on dev eth0
I''m most perplexed as to where to look...
interfaces:
rw ipsec+
zones:
rw RoadWarriors Road Warriors
policy:
rw rw ACCEPT
rw loc ACCEPT
loc rw ACCEPT
rw fw ACCEPT
fw rw ACCEPT
Anyway, here are the requested items from the shorewall website for
help requests: :-)
shorewall version
1.4.9
ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:c0:9f:1e:fa:99 brd ff:ff:ff:ff:ff:ff
inet 208.10.57.129/28 brd 208.10.57.143 scope global eth0
inet 208.10.57.130/28 brd 208.10.57.143 scope global secondary
eth0:0
inet 208.10.57.131/28 brd 208.10.57.143 scope global secondary
eth0:1
inet 208.10.57.135/28 brd 208.10.57.143 scope global secondary
eth0:2
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:04:5a:8a:48:05 brd ff:ff:ff:ff:ff:ff
inet 192.168.168.1/24 brd 192.168.168.255 scope global eth1
180: ipsec0: <NOARP,UP> mtu 1280 qdisc pfifo_fast qlen 10
link/ether 00:c0:9f:1e:fa:99 brd ff:ff:ff:ff:ff:ff
inet 208.10.57.129/28 brd 208.10.57.143 scope global ipsec0
181: ipsec1: <NOARP,UP> mtu 1280 qdisc pfifo_fast qlen 10
link/ether 00:c0:9f:1e:fa:99 brd ff:ff:ff:ff:ff:ff
inet 208.10.57.130/28 brd 208.10.57.143 scope global ipsec1
182: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10
link/ipip
183: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10
link/ipip
ip route show
192.168.0.101 via 208.10.57.142 dev ipsec0
208.10.57.128/28 dev eth0 scope link
208.10.57.128/28 dev ipsec0 proto kernel scope link src 208.10.57.129
208.10.57.128/28 dev ipsec1 proto kernel scope link src 208.10.57.130
192.168.168.0/24 dev eth1 scope link
127.0.0.0/8 dev lo scope link
default dev eth0 scope link
if status will help, let me know. I don''t know that this is strictly a
Shorewall issue, but I''m begging for help. :-)
On Wednesday 25 February 2004 08:19 pm, Steven Palm wrote:> [ sorry for cross-posting this to newbies and users, but I''m a bit > desperate to get this resolved ]Then turn off route filtering on eth0 OR turn of martian logging. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thursday 26 February 2004 07:02 am, Tom Eastep wrote:> On Wednesday 25 February 2004 08:19 pm, Steven Palm wrote: > > [ sorry for cross-posting this to newbies and users, but I''m a bit > > desperate to get this resolved ] > > Then turn off route filtering on eth0 OR turn of martian logging.That should have been "turn off martian logging". -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Feb 26, 2004, at 11:29 AM, Tom Eastep wrote:> On Thursday 26 February 2004 07:02 am, Tom Eastep wrote: >> On Wednesday 25 February 2004 08:19 pm, Steven Palm wrote: >>> [ sorry for cross-posting this to newbies and users, but I''m a bit >>> desperate to get this resolved ] >> >> Then turn off route filtering on eth0 OR turn of martian logging. > > That should have been "turn off martian logging".Thanks, I had the route filtering turned off in the shorewall.conf, but it was on in the interfaces file. So, I no longer get those messages, which is good. :-) The tunnel still doesn''t work, but I''m guessing it''s most likely entirely an IPSec problem at this point. I even shut Shorewall off (shorewall clear -- that should do it, right?) and the tunnel won''t build properly. It seems as though FreeS/WAN on Linux is perfectly happy, it goes through and logs that it has reached STATE_MAIN_R3, sent MR3, ISAKMP SA established. However, Racoon on MacOS X seems to think that phase1 is never completed properly and times out, resending, resending... To all of this, FreeS/WAN discards duplicate packets because it thinks it has already reached STATE_MAIN_R3. {sigh} The puzzling part (for me) is that this works perfectly fine if I''m behind a remote router/nat device, but not if I have a public IP. {grumble} Well, it looks like Shorewall is likely not the culprit. Time to go begging elsewhere. :-) Thanks! Steve
On Thursday 26 February 2004 12:19 pm, Steven Palm wrote:> On Feb 26, 2004, at 11:29 AM, Tom Eastep wrote: > > On Thursday 26 February 2004 07:02 am, Tom Eastep wrote: > >> On Wednesday 25 February 2004 08:19 pm, Steven Palm wrote: > >>> [ sorry for cross-posting this to newbies and users, but I''m a bit > >>> desperate to get this resolved ] > >> > >> Then turn off route filtering on eth0 OR turn of martian logging. > > > > That should have been "turn off martian logging". > > Thanks, I had the route filtering turned off in the shorewall.conf, > but it was on in the interfaces file. > > So, I no longer get those messages, which is good. :-) > > The tunnel still doesn''t work, but I''m guessing it''s most likely > entirely an IPSec problem at this point. I even shut Shorewall off > (shorewall clear -- that should do it, right?) and the tunnel won''t > build properly. >Then the problem is not Shorewall-related. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net