Brad Clarke wrote:
I have an apache installed on the shorewall machine. At one time I could make a connection from an internal IP to any of the 3 IPs on the shorewall machine and it would go to the apache server, but now connections to 216.111.163.33 are failing even though the other two addresses work fine. I'm attaching a dump (dump-apache.gz) of me trying to make one of these connections from 192.168.10.220.
That's because 216.111.163.33 isn't the IP address of any of the firewall interfaces. The firewall's eth1 interface has an address that is close:
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:11:43:d5:b5:ed brd ff:ff:ff:ff:ff:ff
inet 207.111.163.33/30 brd 207.111.163.35 scope global eth1
--------------
inet6 fe80::211:43ff:fed5:b5ed/64 scope link
valid_lft forever preferred_lft forever
I had VPN connections from an internal address (192.168.10.x) to either of the external addresses routing the connection back to the internal VPN server.
Actually, you don't. You have what appear to be these rules: DNAT $FW loc:192.168.10.17 tcp 1723 - 207.111.163.33 DNAT $FW loc:192.168.10.17 gre - - 207.111.163.33 You need to replace $FW with 'loc'.A more basic question is though, "Why in &^%$ do you want a loc->loc VPN in the first place?"
Now these connections will not work at all. It was showing up in my log as being REJECTed by the loc2fw rule so I added a rule to allow it (though I don't recall having to do that before).
Before what?
Try as I might I ended up having to remove routefilter from both of my external interfaces because VPN connection attempts from outside were showing up as martians. I think I did everything that was asked of me in the documentation to prevent that from happening but if someone can see anything in the dumps that might point to why I'm still seeing these connections as martians I'd love to be able to turn that option back on.
How could we possibly do that without seeing one of the Martian messages?
It might also be worth telling people somewhere that after removing the routefilter option I had to reboot the machine for it to take effect (I could add it with just a shorewall restart though).
That is a 'feature' of Shorewall 3.4. The Debian Shorewall maintainer makes a 4.0 'Etch' repository available at http://people.connexer.com/~roberto/debian/ and those packages work well on Gutsy.
Should I be setting the metrics on the interfaces like I am or does it matter at all once shorewall does it's thing?
It doesn't matter. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
