From: Tom E. <te...@sh...> - 2002-08-22 14:21:59
|
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.25= 5.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 g= o > 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 thin= k > 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 trie= d > "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 wi= ll=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 eth= 2". > > 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 \ te...@sh... |