I''m using a newly built Ubuntu 7.10 system and the shorewall package available from the gutsy repository. I have made the two patches for multi-ISP users listed on the home page. I think my setup might have gotten a little too complex for my brain but it seems like I have everything in place. I have 2 ISPs on 2 different interfaces and 1 more interface for my local network. I''m forwarding VPN connections made to either of the public IP addresses to an internal VPN server. During setup (I''ve gone through quite a bit of trial and error so I don''t recall exactly how setup things were at the time) both of the following were working but now that I have everything else in place I can''t make it happen anymore 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. 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. 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). There is no longer anything in the log but the connection will still not happen. I''m attaching a dump of that attempt as well (dump-vpn.gz). There are also a couple of other things that are bugging me about my configuration that may or may not be related but I''ll mention them at least. 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. 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). Should I be setting the metrics on the interfaces like I am or does it matter at all once shorewall does it''s thing? 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
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 \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
On Sat, Apr 12, 2008 at 9:56 AM, Tom Eastep <teastep@shorewall.net> 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
Brad Clarke wrote:> 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.An incoming packet is considered to be a Martian if the response to that packet would be routed out of a different interface from the one that the incoming packet was received on. So, for example, if the route to 192.168.1.0/24 is out of eth0 and a packet from 192.168.1.4 is received on eth1, that packet is a Martian. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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