On Sat, Apr 12, 2008 at 9:56 AM, Tom Eastep <[EMAIL PROTECTED]> wrote: > > 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:
I knew I was doing something stupid but I thought it was in the configuration not in my testing :) This part was already working as expected. > > > > 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'. The rules were actually "DNAT all loc:192.168.10.17 ..." but your comment pointed me in the right direction. I now recall using a loc/net pair of rules while initially testing and that's when it worked. After carefully reading the shorewall-rules man page I now understand why it started failing: "When all[-] is used either in the SOURCE or DEST column intra-zone traffic is not affected. When all+[-] is "used, intra-zone traffic is affected." Changing the rules from "all" to "all+" fixed the problem, though I should probably go back to the loc/net pair to keep things a little more secure. > A more basic question is though, "Why in &^%$ do you want a loc->loc VPN in > the first place?" The VPN case is rather silly but that was just the first service I was exposing through the firewall so I used it as a test. Next will be a jabber server where the internal clients are using a public DNS name and the server is another machine behind the firewall. BIND views are not an option so I needed to make sure the concept would work. > > 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? I think my problem is I don't understand why they're being seen as martians simply because I added another public interface to my configuration, which probably just means I don't really understand what defines a martian. I really only mentioned it in case it was related to my other problems. With everything now functioning properly it's more of an educational question so I'm not that worried about it anymore, meaning you can just blow me off and I'll go research on my own :) > 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. Good to know :) With the release of hardy so close I'll probably just wait for that since it also has 4.0 available but if I end up using shorewall on one of our etch machines I'll surely make use of this repository. Thank you for all your help! Brad C ------------------------------------------------------------------------- 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
