[TriLUG] IPTables - disable NAT for a specific source/destination

Wed Jun 6 11:15:39 EDT 2018

Thanks Aaron.  By chance, did the PDF diagram make it through the email alias?  I got a message stating the email awaits moderator approval.

As for the return path, you are correct.  We will add a static route on the 172.16 host to ensure it knows how to get back to the 192.168 VM.

Here are the iptable commands we are currently using. 

-------------------------
/sbin/iptables -F  -t nat
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport ssh -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
/sbin/iptables -I INPUT -i eth1 -p udp --dport 67:68 --sport 67:68 -j ACCEPT

/sbin/iptables -t nat -A PREROUTING -s 172.16.100.10 -p tcp --dport 2211 -j DNAT --to-destination 192.168.100.11:22
/sbin/iptables -t nat -A PREROUTING -s 172.16.100.10 -p tcp --dport 2212 -j DNAT --to-destination 192.168.100.12:22
/sbin/iptables -t nat -A PREROUTING -s 172.16.100.10 -p tcp --dport 2213 -j DNAT --to-destination 192.168.100.13:22
/sbin/iptables -t nat -A PREROUTING -s 172.16.100.10 -p tcp --dport 2214 -j DNAT --to-destination 192.168.100.14:22
/sbin/iptables -t nat -A PREROUTING -s 172.16.100.10 -p tcp --dport 2215 -j DNAT --to-destination 192.168.100.15:22

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8811 -j DNAT --to-destination 192.168.100.11:80
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8812 -j DNAT --to-destination 192.168.100.12:80
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8813 -j DNAT --to-destination 192.168.100.13:80
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8814 -j DNAT --to-destination 192.168.100.14:80
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8815 -j DNAT --to-destination 192.168.100.15:80

-------------------------

As you can see, we have two sets of DNAT rules: one for ssh (top DNAT rules) and one for web traffic (bottom DNAT rules).  The goal is to insert a command that provides a connection from 192.168.100.13 to 172.16.100.13 w/out NAT.

From your example below, it seems I might need this command:
------------
/sbin/iptables -I POSTROUTING 1 -s 192.168.100.13 -d 172.16.100.13 -j RETURN
------------

If correct, where should we put this rule?  Above/below the PREROUTING rules or somewhere else?

Hope this makes it more clear.

Thanks for the assistance!

-Ron

> On Jun 6, 2018, at 11:05 AM, Aaron Joyner via TriLUG <trilug at trilug.org> wrote:
> 
> There's a simple answer to your question, but read on, because there is
> another problem you are likely to stumble on.  Packages traverse an
> iptables chain until they hit a terminating action, typically one of
> ACCEPT, DROP, or RETURN.  You can use this behavior to stop processing of
> the NAT table's POSTROUTING chain before it encounters the target which
> would apply the MASQUERADE behavior, only for that host.  Site-unseen, you
> can probably put insert a rule in position 1 to achieve that effect:
> 
> $ SRCIP = 192.168.100.42 # The IP in 192.168.100.0/24 that should not be
> translated
> $ iptables -I POSTROUTING 1 -s $SRCIP -j RETURN
> 
> Assuming you want $SRCIP to also be able to reach the internet through this
> NAT gatweay, you likely also want to add "-d 172.16.100.0/24" to that
> command, so that it doesn't NAT only when talking to hosts in that subnet.
> 
> This will get your packet from $SRCIP to the hosts in the 172.16.100.0/24
> subnet... but it's unlikely they know how to route back to $SRCIP.  You'll
> also need a route on hosts in the 172.16.100.0/24 subnet to direct their
> traffic to 192.168.100.0/24 (including response packets) to the gateway
> IP.  Assuming the gateway's IP is 172.16.100.1, that would look like this:
> 
> $ ip route add 192.168.100.0/24 via 172.16.100.1
> 
> Aaron S. Joyner
> 
> On Wed, Jun 6, 2018 at 9:14 AM, Brian Henning via TriLUG <trilug at trilug.org>
> wrote:
> 
>> I think there may be some confusion of terms going on here.
>> 
>> A "firewall" decides what packets to allow through or not.
>> A "router" handles modifying envelope data to get packets along to the
>> next hop.
>> 
>> NAT is a routing function.  iptables does both firewalling and routing.
>> 
>> Perhaps Huan is guessing your intent correctly (a DMZ), but that's not
>> what I'm getting from your description.
>> 
>> Can you describe the intent some more, perhaps give an example situation
>> where NAT is not what you want?
>> 
>> Cheers,
>> -Brian
>> 
>> 
>> -----Original Message-----
>> From: TriLUG [mailto:trilug-bounces+bhenning=pineresearch.com at trilug.org]
>> On Behalf Of Ron Kelley via TriLUG
>> Sent: Wednesday, June 06, 2018 8:24 AM
>> To: Triangle Linux Users Group General Discussion <trilug at trilug.org>
>> Subject: [TriLUG] IPTables - disable NAT for a specific source/destination
>> 
>> Greetings all,
>> 
>> I have a test bed running using IPTables on a RHEL 7 server (a “firewall”
>> machine).  This machine provides NAT services for an inside network to an
>> outside network.  For my test, the outside network has the IP space of
>> 172.16.100/0/24, and the inside network has the IP space of
>> 192.168.100.0/24.  The firewall has two IP Addresses:  172.16.100.10
>> (outside) and 192.168.100.1 (inside).
>> 
>> As you might expect, all VMs on the inside network go through the
>> firewall, and their source IP gets NAT’d to the 172.16.100.10 IP.  All
>> working well.
>> 
>> However, I have a unique requirement for one of the inside VMs to go
>> through the firewall w/out a NAT address.  Essentially, this particular
>> machine needs a “no nat” statement in the IPTables rules.  In this case,
>> the firewall is simply a router.
>> 
>> I have searched google for any sort of “no nat” example but can’t find
>> it.  Does anyone have a sample they can share?
>> 
>> 
>> Thanks,
>> 
>> -Ron
>> --
>> This message was sent to: Brian <bhenning at pineresearch.com> To
>> unsubscribe, send a blank message to trilug-leave at trilug.org from that
>> address.
>> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
>> Unsubscribe or edit options on the web  : https://www.trilug.org/
>> mailman/options/trilug/bhenning%40pineresearch.com
>> Welcome to TriLUG: https://trilug.org/welcome
>> --
>> This message was sent to: Aaron S. Joyner <aaron at joyner.ws>
>> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
>> address.
>> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
>> Unsubscribe or edit options on the web  : https://www.trilug.org/
>> mailman/options/trilug/aaron%40joyner.ws
>> Welcome to TriLUG: https://trilug.org/welcome
>> 
> -- 
> This message was sent to: Ron Kelley <rkelleyrtp at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web	: https://www.trilug.org/mailman/options/trilug/rkelleyrtp%40gmail.com
> Welcome to TriLUG: https://trilug.org/welcome