I''ve used Shorewall on several systems at work (only doing basic stuff), but I''ve just been asked about something a bit out of the ordinary. What is required is a number of separate private (rfc1918) networks*, each nat''d to the public internet. But each private network must be independent of the others - so the only access from one network to another must be by going out through the nat and then going back in through whatever inbound mappings may be configured. It''s for a business centre where different clients will require their own private network and shared internet access - but obviously they should not be able to access each others systems. Just for good measure, in this case there is only one public IP address (not our choice, I''d rather have one ip per client). I can handle the dhcp and dns no problem, and I assume I can handle the ''no access between networks'' by setting the policies to block it. Is it possible to set up the hairpinning so that one client could access a public service provided by another ? Actually, I don''t think it''s likely to be required, but it would be a bit embarassing to set all this up and then find it''s needed and I can''t do it ! Looking in the FAQ I guess I''d be needing a variation on the techniques in section 2. In particular, FAQ2a seems to be the closest, but ideally I''d want the ''looped back'' traffic to appear as being from the public IP address. Anything I''ve missed ? * Each network will be a separate interface - either a separate physical interface, or more likely a separate VLAN on a trunked port to a VLAN capable switch. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Bob Coffman Jr - Info From Data
2007-Jan-03 13:44 UTC
Re: Multiple independent private networks ?
I''ve set up a smaller scenario just as you are describing, minus the public services. Policies indeed will prevent traffic between the different subnets. Since I was only dealing with two separate subnets, I merely added an additional interface into the firewall, but I don''t see why VLANs wouldn''t work.>Is it possible to set up the hairpinning so that one client couldaccess a public service provided by another ? With one public IP, this sounds like a potentially major issue. What if more than one client wants to "own" port 80 for example? What about the restriction of keeping the traffic subnets separate? Also, you are ignoring Tom''s advice from FAQ 2 about having internet accessible hosts in a local subnet. If something like this were absolutely required, I would go the DNS views route, and set up rules for whatever traffic was required. Although the traffic won''t appear to be originating from the public IP, will the end user know or care? I think you would be best served by either obtaining additional public IP addresses or prohibiting hosting through this firewall. - Bob Coffman ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Wed, Jan 03, 2007 at 08:44:43AM -0500, Bob Coffman Jr - Info From Data wrote:> I''ve set up a smaller scenario just as you are describing, minus the public > services. Policies indeed will prevent traffic between the different > subnets. Since I was only dealing with two separate subnets, I merely added > an additional interface into the firewall, but I don''t see why VLANs > wouldn''t work.VLAN trunking works fine for this - that''s how my monstrous 50-interface firewalls are built, doing a similar role. Note that if you''re building something on a similar scale, you will probably run into the same performance issues that I did. Don''t shove every VLAN into its own zone just because you can. You *will* need to consider this when allocating IP address space. See the earlier thread for details. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Bob Coffman Jr wrote:> >Is it possible to set up the hairpinning so that one client could >access a public service provided by another ? > >With one public IP, this sounds like a potentially major issue.Yes, and I expect that it probably won''t happen - but it is something I need to bear in mind. In practice, whilst I can see that one or more client might want to ''host'' something ''public'', it''s more likely that this will be for their own access (eg remote access, or as with a client at another site, incoming rsync connections between two linux boxes at different sites) and access from other clients at the same site won''t be required.>What if more than one client wants to "own" port 80 for example?First come, first served !>What about the restriction of keeping the traffic subnets separate?Well as long as it goes out through the NAT and then back in through whatever access rules are set up for the service, that''s not an issue.>Also, you are ignoring Tom''s advice from FAQ 2 about having internet >accessible hosts in a local subnet.Yes - whatever the advisability or not, in practical terms I think you''ll find that the majority of servers around the world are set up that way.>If something like this were absolutely required, I would go the DNS >views route, and set up rules for whatever traffic was required. Although >the traffic won''t appear to be originating from the public IP, will the end >user know or care?Certainly an option I''ll bear in mind.>I think you would be best served by either obtaining additional public IP >addresses or prohibiting hosting through this firewall.Unfortunately I don''t think either will be possible. Customer is likely to take the attitude that "tenant needs therefore must be provided" and we have no control over the internet connection. It will certainly be a case of "have you a VERY good reason for needing this" when anyone asks ! It''s going to be a case of making the best of what we''ve been stuck with ! Another of our customers installed a VROOM switch (http://baxl.net/mini.htm) and Nomadix gateway (http://www.nomadix.com/products/) so some of us are quietly waiting to see what happens when their customer come along with the same questions :-) Considering that one tenant spent several days on the phone with the people that provide the support for the kit, and no-one realised that a modem doesn''t work when plugged into an ethernet port, we think it could be ''interesting'' to watch ! ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Andrew Suffield wrote:>VLAN trunking works fine for this - that''s how my monstrous >50-interface firewalls are built, doing a similar role.Do you have recommendations for ethernet cards that work well with VLAN trunks ?>Note that if >you''re building something on a similar scale, you will probably run >into the same performance issues that I did. Don''t shove every VLAN >into its own zone just because you can. You *will* need to consider >this when allocating IP address space. See the earlier thread for >details.I vaguely recall the thread, but the archives seem to stop a couple of months ago :-( Can you summarise the key setup details you worked out ? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Simon Hobson wrote:> Andrew Suffield wrote: >> Note that if >> you''re building something on a similar scale, you will probably run >> into the same performance issues that I did. Don''t shove every VLAN >> into its own zone just because you can. You *will* need to consider >> this when allocating IP address space. See the earlier thread for >> details. > > I vaguely recall the thread, but the archives seem to stop a couple > of months ago :-( > > Can you summarise the key setup details you worked out ?Some of the issues raised in that thread are discussed at http://www1.shorewall.net/ScalabilityAndPerformance.html -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Wed, Jan 03, 2007 at 03:15:20PM +0000, Simon Hobson wrote:> Andrew Suffield wrote: > > >VLAN trunking works fine for this - that''s how my monstrous > >50-interface firewalls are built, doing a similar role. > > Do you have recommendations for ethernet cards that work well with > VLAN trunks ?We mostly use Intel e1000-based cards because they''re usually dependable for any purpose - they weren''t chosen specifically for VLAN support. Any non-broken card should work with Linux''s software implementation of 802.1q. I don''t have any particular knowledge about which cards support hardware-accelerated VLAN processing, but it doesn''t really seem important. That''s not going to be the bottleneck.> >Note that if > >you''re building something on a similar scale, you will probably run > >into the same performance issues that I did. Don''t shove every VLAN > >into its own zone just because you can. You *will* need to consider > >this when allocating IP address space. See the earlier thread for > >details. > > I vaguely recall the thread, but the archives seem to stop a couple > of months ago :-(I think they''re just plain broken. I can send you a copy if you want.> Can you summarise the key setup details you worked out ?Don''t create more zones than you actually need. Don''t put one line in shorewall/interfaces for each VLAN (shorewall''s performance is subtly sensitive to what you put in the interfaces and hosts files), instead collect all the roughly-equivalent client networks with a wildcard line, and do any per-VLAN variations in shorewall/rules - which means your client networks need to have addresses that make this convinient. Use return-path filtering to ensure that client networks must use the correct addresses (so no assymetric routing), so you can rely on them for filtering purposes. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Andrew Suffield wrote:> On Wed, Jan 03, 2007 at 03:15:20PM +0000, Simon Hobson wrote:>> I vaguely recall the thread, but the archives seem to stop a couple >> of months ago :-( > > I think they''re just plain broken. I can send you a copy if you want.The archives at sourceforge are totally broken (see https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1610557&group_id=1). Use the archives at gmane instead (http://dir.gmane.org/gmane.comp.security.shorewall). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Andrew Suffield wrote:> On Wed, Jan 03, 2007 at 03:15:20PM +0000, Simon Hobson wrote: > >> Can you summarise the key setup details you worked out ? > > Don''t create more zones than you actually need. Don''t put one line in > shorewall/interfaces for each VLAN (shorewall''s performance is subtly > sensitive to what you put in the interfaces and hosts files), instead > collect all the roughly-equivalent client networks with a wildcard > line, and do any per-VLAN variations in shorewall/rules - which means > your client networks need to have addresses that make this > convinient. Use return-path filtering to ensure that client networks > must use the correct addresses (so no assymetric routing), so you can > rely on them for filtering purposes.You can use vlan interfaces for filtering, even if they aren''t explicitly mentioned in /etc/shorewall/interfaces. Example: /etc/shorewall/interfaces: foo eth1.1* ... /etc/shorewall/rules: ACCEPT foo:eth1.12 ... If you find that feature is broken with vlans, let me know as it should work. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Wed, Jan 03, 2007 at 10:13:46AM -0800, Tom Eastep wrote:> Andrew Suffield wrote: > > On Wed, Jan 03, 2007 at 03:15:20PM +0000, Simon Hobson wrote: > > > >> Can you summarise the key setup details you worked out ? > > > > Don''t create more zones than you actually need. Don''t put one line in > > shorewall/interfaces for each VLAN (shorewall''s performance is subtly > > sensitive to what you put in the interfaces and hosts files), instead > > collect all the roughly-equivalent client networks with a wildcard > > line, and do any per-VLAN variations in shorewall/rules - which means > > your client networks need to have addresses that make this > > convinient. Use return-path filtering to ensure that client networks > > must use the correct addresses (so no assymetric routing), so you can > > rely on them for filtering purposes. > > You can use vlan interfaces for filtering, even if they aren''t explicitly > mentioned in /etc/shorewall/interfaces.Hmm, yes, that''s obvious when you think about it. I can''t remember why I had to do it the other way. Must be something weird about my setup. Ignore that bit. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On 3/1/07, Andrew Suffield wrote:> > Do you have recommendations for ethernet cards that work well with >> VLAN trunks ? > >We mostly use Intel e1000-based cards because they''re usually >dependable for any purpose - they weren''t chosen specifically for VLAN >support. Any non-broken card should work with Linux''s software >implementation of 802.1q.The box I''m currently testing on has an e100 card in it, so works fine.> > Can you summarise the key setup details you worked out ? > >Don''t create more zones than you actually need. Don''t put one line in >shorewall/interfaces for each VLAN (shorewall''s performance is subtly >sensitive to what you put in the interfaces and hosts files), instead >collect all the roughly-equivalent client networks with a wildcard >line, and do any per-VLAN variations in shorewall/rules - which means >your client networks need to have addresses that make this >convinient. Use return-path filtering to ensure that client networks >must use the correct addresses (so no assymetric routing), so you can >rely on them for filtering purposes.I''ve got stuff almost sorted now, but obviously vlan-vlan security is important - will be different tenants. It appears that I can''t combine wildcards with route filtering and arp filtering, so if I put : cust vlan+ detect tcpflags,nosmurfs,routeback,dhcp,routefilter,arp_filter,arp_ignore=2 in my interfaces file, I get : WARNING: Cannot set ARP filtering on vlan+ WARNING: Cannot set ARP filtering on vlan+ WARNING: Cannot set route filtering on vlan+ in shorewalls output. Other than listing each vlan separately (there''s 32 of them on this box), is it possible to set these options ? I''m using a simple mapping between vlan and ip address, eg vlan101 is ip 10.1.101.0/24, vlan102 is 10.1.102.0/24 and so on. I''m impressed with shorewall, all the time I keep finding more features that I can actually understand ! ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Simon Hobson wrote:> > I''ve got stuff almost sorted now, but obviously vlan-vlan security is > important - will be different tenants. It appears that I can''t > combine wildcards with route filtering and arp filtering, so if I put > : > > cust vlan+ detect > tcpflags,nosmurfs,routeback,dhcp,routefilter,arp_filter,arp_ignore=2 > > in my interfaces file, I get : > WARNING: Cannot set ARP filtering on vlan+ > WARNING: Cannot set ARP filtering on vlan+ > WARNING: Cannot set route filtering on vlan+ > > in shorewalls output. > > Other than listing each vlan separately (there''s 32 of them on this > box), is it possible to set these options ?Sure -- set them yourself in a simple shell script (or if you are using a Debian-based distribution, set the options in a ''post-up'' record in your interfaces file. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> > I''ve got stuff almost sorted now, but obviously vlan-vlan security is >> important - will be different tenants. It appears that I can''t >> combine wildcards with route filtering and arp filtering, so if I put >> : >> >> cust vlan+ detect >> tcpflags,nosmurfs,routeback,dhcp,routefilter,arp_filter,arp_ignore=2 >> >> in my interfaces file, I get : >> WARNING: Cannot set ARP filtering on vlan+ >> WARNING: Cannot set ARP filtering on vlan+ >> WARNING: Cannot set route filtering on vlan+ >> >> in shorewalls output. >> >> Other than listing each vlan separately (there''s 32 of them on this >> box), is it possible to set these options ?>Sure -- set them yourself in a simple shell script (or if you are using a >Debian-based distribution, set the options in a ''post-up'' record in your >interfaces file.Can I just confirm I''ve got this right. I''m using Debian Etch, so in interfaces I''ve put : up echo 1 > /proc/sys/net/ipv4/conf/vlan101/arp_filter up echo 2 > /proc/sys/net/ipv4/conf/vlan101/arp_ignore up echo 1 > /proc/sys/net/ipv4/conf/vlan101/rp_filter in the vlan101 stanza and similarly for the other interfaces. arp_filter and arp_ignore are obvious, I assume routefilter maps to the rp_filter file ? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Simon Hobson wrote:> > Can I just confirm I''ve got this right. I''m using Debian Etch, so in > interfaces I''ve put : > > up echo 1 > /proc/sys/net/ipv4/conf/vlan101/arp_filter > up echo 2 > /proc/sys/net/ipv4/conf/vlan101/arp_ignore > up echo 1 > /proc/sys/net/ipv4/conf/vlan101/rp_filter > in the vlan101 stanza and similarly for the other interfaces.Looks good.> > arp_filter and arp_ignore are obvious, I assume routefilter maps to > the rp_filter file ? >Yes. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV