Re: [Shorewall-users] Questions about NAT and MASQ and more

[Tom E. <te...@sh...>]

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...