[Firewall] Other NAT rules fail when source specific rule is added

Lonnie Abelbeck lists at lonnie.abelbeck.com
Thu Feb 6 16:05:56 CET 2014


On Feb 6, 2014, at 5:57 AM, Alex Aune wrote:

> On 20.09.2013 14:03, Alex Aune wrote:
>> Hi everyone,
>> I had some downtime at work the other day so decided to try and work
>> around the firewall here to give myself shell access at home using
>> port 443. I already have a webserver running on 443 so I had a go with
>> setting up a source specific NAT rule.
>> Now, as soon as I added 1.2.3.4/30~443>10.0.0.1~22 (to
>> NAT_FORWARD_TCP) my more general rule of 80,443>10.0.0.18 no longer
>> works. If I run "telnet aewne.net 443" I am greeted by the OpenSSH
>> server, even when traffic is not originating from the same IP
>> address/subnet in the rule.
>> However, if I add a source/subnet declaration (0/0~80,443>10.0.0.18)
>> it works like it should.
>> Is this a known issue?
>> I'm using 2.0.1d (-r2 version of the Gentoo ebuild) with coreutils 8.21.
>> Regards,
>> Alex
> 
> Ok, I've had some time to play a bit more with this...
> 
> Firstly, it seems that I forgot to mention a few things in my setup.
> One is that I'm using the NAT loopback plugin to hairpin requests to my external DNS name originating from the LAN. While I'm on the subject, hairpinning is kind of lazy. Are there any other ways to solve this?
> Second is that it's only if I'm trying to connect to my internal web server using my external DNS name (aewne.net) that I'm greeted by the SSH server. So, for external requests to port 443 this is working correctly, as well as traffic from the specific source I set up in the config is working. However, not from LAN -> gateway -> Host on LAN.
> 
> I also found out that this:
>> However, if I add a source/subnet declaration (0/0~80,443>10.0.0.18)
> Is bogus. Adding 0/0 didn't seem to help much after all.
> 
> Looking at the output of iptables -nvL -t nat it is apparent that the source specific rule is way up above the more general rule, meaning, at least in theory, that the specific rule should only trigger on incoming traffic from that address.
> 
> So, I'm having a hard time tracking down the culprit here. Anyone got any ideas?
> 
> Alex

Fundamentally, if you are trying to NAT packets with the same public destination port to different internal addresses you need more than one public IPv4 address to steer the packet properly.  It appears you are trying to use the public packet's source address to steer the public 443 port packet internally...  possibly some clever hack using /etc/arno-iptables-firewall/custom-rules but at first look it seems AIF requires multiple public IPv4 addresses for multiple internal servers for the same port, each accessed by the different public IPv4 address.

Keep in mind this NAT trickery must not only make the packet arrive on the proper internal server, but the internal server's return packet must make it back to the sender.

As far as an alternative to the NAT loopback plugin, a local DNS server/forwarder could map local LAN requests to a local private address while the public DNS maps the request to your public address.

Lonnie




More information about the Firewall mailing list