I''m setting up Shorewall (4.4.26.1), and have been trying to figure out routing between two LAN segments now for a few days. It''s time to ask for help. I have three NICs: WAN (Internet), LAN1 (primary LAN), and LAN2 (link to a "legacy" LAN). WAN-to-LAN is working inbound through NAT, and outbound through DNAT (set in masq). LAN2 should not (and currently does not) have access to the Internet through this Shorewall instance (it has its own route to the Internet), and it should not be able to access LAN1, but it should be accessible from LAN1. I''m currently able to get to LAN2 from the Shorewall server, but not from the other servers in LAN1 (which is the problem). The necessary rules are in place, but apparently routing isn''t working. If I disable the firewall access rules, I get immediate "connection refused" when attempting to connect to a server in LAN2 from a server in LAN1. When firewall access rules are enabled, SSH simply hangs and traceroute doesn''t go beyond the firewall. LAN1 (primary) is in the 172.0.0.0 address space and LAN2 (legacy) is in the 10.0.0.0 address space. I currently have: $LAN2_IF 10.0.0.0/24 .. in masq, but that''s not working ($LAN2_IF resolves to eth2 which is the LAN2 interface). My question is: What is the simplest Shorewall configuration to forward traffic between two differently addressed LAN segments that are connected to separate NICs? A pointer to documentation or other reference would help, a bare-bones config example would be even better. I''ve been sifting through the Shorewall documentation on routing, but haven''t yet found a matching description (for instance, I would rather not have to bridge the LAN1 and LAN2 interfaces if it can be avoided since they need to remain separated: LAN2 should not have access either to the Internet or LAN1). This is my first Shorewall setup, so the solution may be really obvious. Thanks for any advice! Ville ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/01/2013 09:12 AM, Ville Walveranta wrote:> I''m setting up Shorewall (4.4.26.1), and have been trying to figure out > routing between two LAN segments now for a few days. It''s time to ask > for help. > > I have three NICs: WAN (Internet), LAN1 (primary LAN), and LAN2 (link to > a "legacy" LAN). WAN-to-LAN is working inbound through NAT, and > outbound through DNAT (set in masq). LAN2 should not (and currently > does not) have access to the Internet through this Shorewall instance > (it has its own route to the Internet), and it should not be able to > access LAN1, but it should be accessible from LAN1. > > I''m currently able to get to LAN2 from the Shorewall server, but not > from the other servers in LAN1 (which is the problem). The necessary > rules are in place, but apparently routing isn''t working. If I disable > the firewall access rules, I get immediate "connection refused" when > attempting to connect to a server in LAN2 from a server in LAN1. When > firewall access rules are enabled, SSH simply hangs and traceroute > doesn''t go beyond the firewall. LAN1 (primary) is in the 172.0.0.0 > address space and LAN2 (legacy) is in the 10.0.0.0 address space. > > I currently have: > > $LAN2_IF 10.0.0.0/24 <http://10.0.0.0/24> > > .. in masq, but that''s not working ($LAN2_IF resolves to eth2 which is > the LAN2 interface). > > My question is: What is the simplest Shorewall configuration to forward > traffic between two differently addressed LAN segments that are > connected to separate NICs? A pointer to documentation or other > reference would help, a bare-bones config example would be even better. > I''ve been sifting through the Shorewall documentation on routing, but > haven''t yet found a matching description (for instance, I would rather > not have to bridge the LAN1 and LAN2 interfaces if it can be avoided > since they need to remain separated: LAN2 should not have access either > to the Internet or LAN1). > > This is my first Shorewall setup, so the solution may be really > obvious. Thanks for any advice!Please forward the output of ''shorewall dump'' collected as described at http://www.shorewall.net/support.htm#guidelines. Thanks, -Tom PS -- Except when you are using Shorewall''s Multi-ISP feature or Proxy ARP, Shorewall is uninvolved in routing. -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/01/2013 09:12 AM, Ville Walveranta wrote:> I''m setting up Shorewall (4.4.26.1), and have been trying to figure out > routing between two LAN segments now for a few days. It''s time to ask > for help. > > I have three NICs: WAN (Internet), LAN1 (primary LAN), and LAN2 (link to > a "legacy" LAN). WAN-to-LAN is working inbound through NAT, and > outbound through DNAT (set in masq). LAN2 should not (and currently > does not) have access to the Internet through this Shorewall instance > (it has its own route to the Internet), and it should not be able to > access LAN1, but it should be accessible from LAN1. > > I''m currently able to get to LAN2 from the Shorewall server, but not > from the other servers in LAN1 (which is the problem). The necessary > rules are in place, but apparently routing isn''t working. If I disable > the firewall access rules, I get immediate "connection refused" when > attempting to connect to a server in LAN2 from a server in LAN1. When > firewall access rules are enabled, SSH simply hangs and traceroute > doesn''t go beyond the firewall. LAN1 (primary) is in the 172.0.0.0 > address space and LAN2 (legacy) is in the 10.0.0.0 address space. > > I currently have: > > $LAN2_IF 10.0.0.0/24 <http://10.0.0.0/24> > > .. in masq, but that''s not working ($LAN2_IF resolves to eth2 which is > the LAN2 interface). >Before forwarding the dump output, try: $LAN2_IF 0.0.0.0/0 -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
Ville Walveranta wrote:> I have three NICs: > WAN (Internet), > LAN1 (primary LAN), > and LAN2 (link to a "legacy" LAN). > WAN-to-LAN is working inbound through NAT, and outbound through DNAT (set in masq). > LAN2 should not (and currently does not) have access to the Internet through this Shorewall instance (it has its own route to the Internet), and it should not be able to access LAN1, but it should be accessible from LAN1.I think all it should take is to put : $wan $lan1 in masq where $wan and $lan1 are the relevant interfaces. That will masq lan1 out though wan, but do nothing for lan2-wan or lan1-lan2 traffic. Then add the appropriate policies and rules. BUT, you will also need the right routes. It is not sufficient to have a route from LAn1 to Lan2, there must also be a route from LAN2 to LAN1. Assuming that this gateway is the default router for LAN1 then half of that is covered, but you must also to to the default router for LAN2 and add a static route to LAN1 via the LAN2 interface of this Shorewall box on LAN2. Without this static route, you can send traffic to LAN2 from LAN1, but you''ll never see any replies - the default gateway on LAN2 will either drop it (not a routable address) or send it out via it''s WAN connection (where it will be dropped as non-routeable). If you cannot add that route in LAN2''s default gateway, then you''ll have to masq LAN1 to LAN2 (add "$lan2 $lan1") so all the traffic appears to come from your gateway box. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
Simon, Thanks for that guidance! It was enough for me to complete the configuration. As you suggested, adding the return route to LAN2''s router helped – I had completely overlooked it thinking that the return route would automatically follow the same path as the incoming request (from LAN1). I also added a specific address in masq (the interface address of the Shorewall box facing LAN2) to ensure that all the requests will appear to be coming from the Shorewall gateway, in other words: $LAN2_IF 10.0.0.0/24 10.0.0.253 Thanks again! Ville ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
On 02/01/2013 01:55 PM, Ville Walveranta wrote:> Simon, > > Thanks for that guidance! It was enough for me to complete the > configuration. As you suggested, adding the return route to LAN2''s > router helped – I had completely overlooked it thinking that the return > route would automatically follow the same path as the incoming request > (from LAN1). I also added a specific address in masq (the interface > address of the Shorewall box facing LAN2) to ensure that all the > requests will appear to be coming from the Shorewall gateway, in other > words: > > $LAN2_IF 10.0.0.0/24 10.0.0.253 >I doubt that entry is doing anything useful. It says "Any packets routed out to LAN2 that have a source address in 10.0.0.0/24 should have the source changed to 10.0.0.253". -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
Tom, you are correct, of course. Someone else pointed that out to me shortly after I had posted the response. I removed the statement and it made no difference in how the configuration works – the problem was solely the missing return route from LAN2. Ville On Fri, Feb 1, 2013 at 4:03 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 02/01/2013 01:55 PM, Ville Walveranta wrote: > > Simon, > > > > Thanks for that guidance! It was enough for me to complete the > > configuration. As you suggested, adding the return route to LAN2''s > > router helped – I had completely overlooked it thinking that the return > > route would automatically follow the same path as the incoming request > > (from LAN1). I also added a specific address in masq (the interface > > address of the Shorewall box facing LAN2) to ensure that all the > > requests will appear to be coming from the Shorewall gateway, in other > > words: > > > > $LAN2_IF 10.0.0.0/24 10.0.0.253 > > > > I doubt that entry is doing anything useful. It says "Any packets routed > out to LAN2 that have a source address in 10.0.0.0/24 should have the > source changed to 10.0.0.253". > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
Re-added it like this: $LAN2_IF 172.16.0.0/24 10.0.0.253 Now it should change the addresses for the connections originating from LAN1 and destined to LAN2, to 10.0.0.253 (which is the Shorewall server address). Ville ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
Ville Walveranta wrote:> Re-added it like this: > $LAN2_IF 172.16.0.0/24 10.0.0.253 > Now it should change the addresses for the connections originating from LAN1 and destined to LAN2, to 10.0.0.253 (which is the Shorewall server address).You may want to have a think about that, and perhaps discuss it with other if systems on LAN2 are managed by other people. First problem is that all connections appear to come from one address, which makes diagnosis of problems more difficult. Second, there are some setups where it breaks things. At work they decided that they''d force the devs to use a VPN to access (Windows) servers on our ''backend'' network. Then they came to me complaining that "the network is broken". After much head scratching, it turns out that the VPN drops if anoher connection comes in from the same address. So if two devs were working, their VPN clients would constantly drop and reconnect. I tried setting up all the routing to remove the NAT, but unfortuntely there''s a Zyxel ZyWall in the loop that refuses to play ball with the triangular routing we end up with. So if everything works fine without NAT, then I''d run it without NAT. The only problem would be if on the LAN2 side of things there is another 172.16.0/24 network (or overlap). ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
That''s a good point... except that in this case, without the masq entry: $LAN2_IF 172.16.0.0/24 10.0.0.253 .. routing doesn''t work. Traceroute won''t proceed beyond the shorewall box from LAN1 servers without it. In this case it doesn''t really matter. LAN2 is a small "legacy" LAN and the point of access to it simply provides an easy way to move data to the servers in the new LAN as the old servers are retired. However, it would be interesting to know (for future reference) why the masq entry seem to be required in this case. LAN2''s router/gateway is a pfSense 2 instance. Thanks again, Ville ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
Ville Walveranta wrote:> That's a good point... except that in this case, without the masq entry:> $LAN2_IF 172.16.0.0/24 10.0.0.253> .. routing doesn't work. Traceroute won't proceed beyond the shorewall box from LAN1 servers without it.Time to break out a packet sniffer (I tend to use tshark) and follow the packets. Do the packets get through your Shorewall box ? Do they go out the right interface ? Do they get past any filters and make it to the wire ? Does the remote machine actually respond ? Where does it send it's packets ? Do they reach your Shorewall box ? (Does the pfsense machine need some rules as well as a route adding ?) Does your Shorewall box bring them back to your own network ? Do they make it out onto the wire ? If in doubt, sit down with a piece of paper, draw your network, and draw the route packets will (or should) take for the round trip. Then use a packet sniffer and follow that route - at some point you should find where the packets stop (or are headed the wrong way) and then you know where to look for the problem. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users