Hello, I''m working on a Shorewall-1.2 setup on a _remote_ debian (woody) firewall with several live web and mail servers behind it. I know doing this remotely is a *really* bad idea, and I''d rather not be in this situation, but so it goes... Worst case scenario, I lock myself out and have to drive an hour to get physical access to the machine and restore service. Anyhow, that out of the way, here''s my setup: (net ip''s are obfuscated here to protect privacy of the people i''m doing this for, and lines from config files are >quoted) First, my /etc/shorewall/interfaces file:> #ZONE INTERFACE BROADCAST OPTIONS > net eth2 detect routestopped,multi > loc eth1 192.168.2.255 routestopped,dhcp > dmz eth0 192.168.1.255 routestoppedSo, I''ve got eth2 on the internet, configured (in /etc/network/interfaces) to use the IP address 64.x.x.146. I''ve got eth1 on a 192.168.2.x LAN with DHCP. All the machines on the LAN should be masq''ed behind a single external IP, so I have this in my /etc/shorewall/masq file:> eth2 eth1 64.x.x.146Next, I''ve got eth0 as the DMZ. The dmz network is using 192.168.1.x addresses, and has some different needs. I''ve got this in my /etc/shorewall/nat file:> 64.x.x.147 eth2 192.168.1.101 yes yes > 64.x.x.148 eth2 192.168.1.100 yes yes > 64.x.x.149 eth2 192.168.1.102 yes yesSo the three servers, .100 .101 and .102, should each have an entire external IP address pointed to them. And they should be accessible at their _external_ (64.x) IP''s from internal hosts, on the DMZ _and_ the LAN. (Is this correct? I don''t believe I''ve messed up so far, but I''m not certain.) This is important, so that people on the lan can access their mailserver (in the dmz) by it''s realworld IP address. Thats part of what I''m having trouble with though (more on that in a bit). Next, I''ve got some ports forwarded, from yet another external IP, to a couple internal hosts. Here are the relevant lines from my /etc/shorewall/rules (there are many more, but they are all just more ACCEPT rules that shouldn''t break anything - I can post them too if needed):> # forward ports: > ACCEPT net dmz:192.168.1.150 tcp domain,smtp,pop3 - > 64.x.x.150 > ACCEPT loc dmz:192.168.1.150 tcp domain,smtp,pop3 - > 64.x.x.150 > ACCEPT net dmz:192.168.1.151 tcp ftp - 64.x.x.150 > ACCEPT loc dmz:192.168.1.151 tcp ftp - 64.x.x.150 > # services allowed throughout the dmz: > ACCEPT net dmz tcp ftp,www,pop3,smtp,domain,sshThe port forwarding through 64.x.x.150 didn''t seem to be working initially, so this was added to the /etc/network/interfaces file:> iface eth2 inet static > address 64.x.x.146 > netmask 255.255.255.0 > network 64.x.x.0 > broadcast 64.x.x.255 > gateway 64.x.x.145 > up ifconfig eth2:0 64.x.x.150(just the last line was added, the rest was already there). So, now:> # ifconfig eth2:0 > eth2:0 Link encap:Ethernet HWaddr 00:04:5A:68:33:98 > inet addr:64.x.x.150 Bcast:64.255.255.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:9 Base address:0xf000I''m not sure if adding the .150 address like that is the right way to go about doing things, and I suspect it isn''t. However, it _did_ make it work as I wanted (the internet at large now has access to 64.x.x.150 as desired). However, smtp connections to the external address are very very slow, and internally (connecting to 192.168.1.150) they aren''t. Telnetting to port 25, it takes over 10 seconds for the smtp banner to come up. This is a minor nuisance, but I''ve got bigger problems too. So, finally, here is my policy file:> dmz net ACCEPT > loc net ACCEPT > loc dmz ACCEPT > loc fw ACCEPT * > dmz fw ACCEPT * > net all DROP info > all all REJECT info* The ->fw accept policies are in there for testing right now and will be removed later. *deep breath* Under the current setup, the outside world can access the servers, and the internal lan users can access the internet. (This is the high-priority stuff :) HOWEVER, internal clients can''t access (or even ping) any of the external IP''s except 64.x.x.146. While looking into this, I''ve found some strange things:> # ifconfig eth2 > eth2 Link encap:Ethernet HWaddr 00:04:5A:68:33:98 > inet addr:64.x.x.148 Bcast:0.0.0.0 Mask:255.255.255.255 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:548735 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:602192 dropped:0 overruns:0 > carrier:1204202 > collisions:0 txqueuelen:100 > RX bytes:118205364 (112.7 MiB) TX bytes:0 (0.0 b) > Interrupt:9 Base address:0xf000What''s strange here is that that eth2 should be configured to use 64.x.x.146 as it''s inet address! I believe it''s shorewall that changes it to .148 (and sometimes .147 !), because these ip addresses aren''t mentioned anywhere in the system besides the shorewall nat file. I think it''s important to notice that the netmask on eth2 is 255.255.255.255, which can''t be right, while eth2:0 (see above) is 255.255.255.0. I tried "ifconfig eth2 netmask 255.255.255.0" but it doesn''t change it. I''m getting well beyond my current networking knowledge now, and I can''t understand how this machine is successfully receiving traffic for 64.x.x.146, 64.x.x.147, 64.x.x.148, 64.x.x.149, and 64.x.x.150, while only having 64.x.x.148 and 64.x.x.150 appear under the "ifconfig -a" listing. (Should that even be possible?) I''d appreciate any clarification the list can provide, as well as a solution to allow the internal lan computers to be able to access the servers in the DMZ by their 64.x.x.x addresses. Any suggestions about what causes the slowness when connecting to the internal smtp server would be nice too. I also just realized, much to my dismay, that the shorewall docs online are for version 1.3 and I''ve got 1.2 installed. This was all installed recently, and I got shorewall via debian''s apt-get. I know I should probably upgrade manually now, and I will eventually, but I don''t want to risk breaking things at this moment (I''m many miles away, and the web+mail servers are currently functional). I hope that I can still get some help with the old version, as an upgrade isn''t really feasible at this time. I wish apt-get hadn''t installed 1.2.12-1 to begin with! Thanks to all who have actually read this far, -phyxeld p.s.: Thank you much, Tom, for writing shorewall in the first place! I''ve used it to quickly setup firewalls for people several times in the past, and it''s always been great. I''ll have to checkout this version 1.3 sometime... ;)
On Thursday 22 August 2002 01:11 am, phyxeld wrote:> > The port forwarding through 64.x.x.150 didn''t seem to be working > > initially, so this was added to the /etc/network/interfaces file: > > iface eth2 inet static > > address 64.x.x.146 > > netmask 255.255.255.0 > > network 64.x.x.0 > > broadcast 64.x.x.255 > > gateway 64.x.x.145 > > up ifconfig eth2:0 64.x.x.150 > > (just the last line was added, the rest was already there). > > So, now: > > # ifconfig eth2:0 > > eth2:0 Link encap:Ethernet HWaddr 00:04:5A:68:33:98 > > inet addr:64.x.x.150 Bcast:64.255.255.255 Mask:255.255.255.0 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > Interrupt:9 Base address:0xf000 > > I''m not sure if adding the .150 address like that is the right way to go > about doing things, and I suspect it isn''t. However, it _did_ make it > work as I wanted (the internet at large now has access to 64.x.x.150 as > desired).That is the only way to make that work.> However, smtp connections to the external address are very > very slow, and internally (connecting to 192.168.1.150) they aren''t. > Telnetting to port 25, it takes over 10 seconds for the smtp banner to > come up. This is a minor nuisance, but I''ve got bigger problems too.Reverse DNS slowness?> > So, finally, here is my policy file: > > dmz net ACCEPT > > loc net ACCEPT > > loc dmz ACCEPT > > loc fw ACCEPT * > > dmz fw ACCEPT * > > net all DROP info > > all all REJECT info > > * The ->fw accept policies are in there for testing right now and will > be removed later. > > *deep breath* > > Under the current setup, the outside world can access the servers, and > the internal lan users can access the internet. (This is the > high-priority stuff :) > HOWEVER, internal clients can''t access (or even ping) any of the > external IP''s except 64.x.x.146. While looking into this, I''ve found > > some strange things: > > # ifconfig eth2 > > eth2 Link encap:Ethernet HWaddr 00:04:5A:68:33:98 > > inet addr:64.x.x.148 Bcast:0.0.0.0 Mask:255.255.255.255 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:548735 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:602192 dropped:0 overruns:0 > > carrier:1204202 > > collisions:0 txqueuelen:100 > > RX bytes:118205364 (112.7 MiB) TX bytes:0 (0.0 b) > > Interrupt:9 Base address:0xf000 > > What''s strange here is that that eth2 should be configured to use > 64.x.x.146 as it''s inet address! I believe it''s shorewall that changes > it to .148 (and sometimes .147 !), because these ip addresses aren''t > mentioned anywhere in the system besides the shorewall nat file. I think > it''s important to notice that the netmask on eth2 is 255.255.255.255, > which can''t be right, while eth2:0 (see above) is 255.255.255.0. I tried > "ifconfig eth2 netmask 255.255.255.0" but it doesn''t change it.What I recommend that you do is turn ADD_IP_ALIASES off in shorewall.conf and=20 add the three static NAT addresses the same way that you did the .150 one=2E If=20 you use ifconfig to look at your ip configuration (as opposed to using ip)=20 you are going to be hopelessly confused otherwise. Even using ''ip'' you will=20 not be totally happy with what you see until you upgrade this site to=20 Shorewall 1.3.x. The command to see what addresses are REALLY on eth2 is "ip addr show eth2".> > I''m getting well beyond my current networking knowledge now, and I can''t > understand how this machine is successfully receiving traffic for > 64.x.x.146, 64.x.x.147, 64.x.x.148, 64.x.x.149, and 64.x.x.150, while > only having 64.x.x.148 and 64.x.x.150 appear under the "ifconfig -a" > listing. (Should that even be possible?)Again, you are using the wrong tool to look at the configuration.> > I''d appreciate any clarification the list can provide, as well as a > solution to allow the internal lan computers to be able to access the > servers in the DMZ by their 64.x.x.x addresses.Do you have appropriate ''loc->dmz'' rules for such access (including ping?)> Any suggestions about > what causes the slowness when connecting to the internal smtp server > would be nice too.Those sorts of problems are best looked at with tcpdump.> > I also just realized, much to my dismay, that the shorewall docs online > are for version 1.3 and I''ve got 1.2 installed.That''s why there are pointers to the 1.2 site :-)> This was all installed > recently, and I got shorewall via debian''s apt-get. I know I should > probably upgrade manually now, and I will eventually, but I don''t want > to risk breaking things at this moment (I''m many miles away, and the > web+mail servers are currently functional). I hope that I can still get > some help with the old version, as an upgrade isn''t really feasible at > this time. I wish apt-get hadn''t installed 1.2.12-1 to begin with!Lorenzo Martignoni maintains an apt-get source that carries the latest=20 Shorewall releases; see the Shorewall download page -- beware though that=20 there are upgrade issues (see http://www.shorewall.net/errata.htm#Upgrade) -Tom --=20 Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Magnus Stenman
2002-Aug-22 14:43 UTC
[Shorewall-users] Questions about NAT and MASQ and more
Tom Eastep wrote:> > On Thursday 22 August 2002 01:11 am, phyxeld wrote: > > >...> > > However, smtp connections to the external address are very > > very slow, and internally (connecting to 192.168.1.150) they aren''t. > > Telnetting to port 25, it takes over 10 seconds for the smtp banner to > > come up. This is a minor nuisance, but I''ve got bigger problems too. > > Reverse DNS slowness?Or ident timeouts. REJECT ident instead of DROPping it can speed things up /magnus> > > > > So, finally, here is my policy file: > > > dmz net ACCEPT > > > loc net ACCEPT > > > loc dmz ACCEPT > > > loc fw ACCEPT * > > > dmz fw ACCEPT * > > > net all DROP info > > > all all REJECT info > >...> > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > AIM: tmeastep \ http://www.shorewall.net > ICQ: #60745924 \ teastep@shorewall.net > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@shorewall.net > http://www.shorewall.net/mailman/listinfo/shorewall-users
On Wednesday 28 August 2002 04:49 pm, phyxeld wrote:> On Thursday, August 22, 2002, at 07:21 AM, Tom Eastep wrote: > > What I recommend that you do is turn ADD_IP_ALIASES off in > > shorewall.conf and > > add the three static NAT addresses the same way that you did the .150 > > one. If > > you use ifconfig to look at your ip configuration (as opposed to using > > ip) > > you are going to be hopelessly confused otherwise. Even using ''ip'' you > > will > > not be totally happy with what you see until you upgrade this site to > > Shorewall 1.3.x. > > > > The command to see what addresses are REALLY on eth2 is "ip addr show > > eth2". > > OK, I''ve upgraded the machine to 1.3.7b using the tarball (after > removing the deb install) and all seems to be working well. BUT, somehow > I keep ending up with a /8 netmask, ie all internet hosts in in the 64.x > class A have become inaccessible (and I''m sending lots of ARP packets > for places I shouldn''t!).The ip utility uses VLSM notation... If you don''t specify a VLSM on the adddress that you add, you get a VLSM supplied based on the old class-based system (which is "/8" on a 64.x.x.x address).> > "ip addr show eth2" shows this: > > 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > > link/ether 00:04:5a:68:33:98 brd ff:ff:ff:ff:ff:ff > > inet 64.x.x.147/8 brd 64.255.255.255 scope global eth2:0 > > inet 64.x.x.148/24 brd 64.255.255.255 scope global eth2 > > inet 64.x.x.150/8 brd 64.255.255.255 scope global secondary eth2:1 > > inet 64.x.x.149/8 brd 64.255.255.255 scope global secondary eth2 > > inet 64.x.x.146/8 brd 64.255.255.255 scope global secondary eth2 > > The .148 was also /8, but I changed it by hand with the ifconfig command. > > How do I set the netmask for each IP using the ip command, or better > still, how do I make shorewall do it when adding aliases? I''d like to > keep shorewall adding my aliases if possible, but 147 and 150 are > currently added with the ifconfig command (in /etc/network/interfaces) > because shorewall didn''t seem to be adding them (.147 has changed since > my last email and isn''t in the nat file anymore).Shorewall can''t add addresses on more than one subnet -- that''s why I told you to add them yourself.> > Where might I find docs for the iproute package? Debian has a > placeholder manpage only.Google tells all... -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net