NAT'ing a subnet for Internet access with IP tables

[rookiepaul]

Hi all,

I have a debian box running as a gateway between my office network, the Internet and a remote subnet via a VPN. I have the office network and the remote subnet talking fine. The remote network is an Amazon Virtual Private Cloud (VPC) which means that for any machines in it to access the Internet, they have to pull the Internet from my office connection through my debian gateway and across the VPN. Internet requests from the VPC hit the debian box but seem to get lost. I think it's a fairly simple solution but my knowledge of IP tables is limited (trying to learn). Network details are as follows:

Office Subnet: 10.121.10.0/24

Debian Office Gateway:
eth0 - 10.121.10.2
eth1 - 213.121.XXX.XXX (Internet Connection)
eth1 alias 1: 169.254.254.2
eth1 alias 2: 169.254.254.6
(eth1 aliases are for the dual VPN tunnels)

VPC Subnet: 10.121.12.0/24

VPC Gatewate (I have no control over this)
inside: 10.121.12.1
outside 1: 169.254.254.1
outside 2: 169.254.254.5
(outside interfaces for VPN tunnels)


As I said earlier, the debian gateway is receiving the Internet requests from the VPC subnet but is dropping them. The VPC and Office are communicating fine. The gateway in the VPC is already configured as it should be to pass Internet traffic to the VPC subnet.

My current iptables config script (bit messy, been trying stuff out):

#!/bin/sh

PATH=/usr/sbin:/sbin:/bin:/usr/bin

#
# delete all existing rules.
#
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

# Always accept loopback traffic
#iptables -A INPUT -i lo -j ACCEPT

# Allow established connections, and not those coming from the outside
#iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#iptables -A INPUT -m state --state NEW -i ! eth1 -j ACCEPT
#iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow outgoing connections from the LAN side.
#iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

# Don't forward from the outside to the inside.
#iptables -A FORWARD -i eth1 -o eth1 -j REJECT

# Enable routing.
#echo 1 > /proc/sys/net/ipv4/ip_forward



#---------------#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -s 10.121.12.0/24 -j ACCEPT
iptables -A INPUT -s 169.254.254.2/30 -j ACCEPT
iptables -A INPUT -s 169.254.254.1/30 -j ACCEPT
iptables -A INPUT -s 169.254.254.6/30 -j ACCEPT
iptables -A INPUT -s 169.254.254.5/30 -j ACCEPT
iptables -A INPUT -s 10.121.10.0/24 -j ACCEPT

iptables -A INPUT -j DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.121.12.0/24 -j ACCEPT
iptables -A FORWARD -s 169.254.254.2/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.1/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.6/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.5/30 -j ACCEPT
iptables -A FORWARD -s 10.121.10.0/24 -j ACCEPT

iptables -A FORWARD -d 169.254.254.0/29 -j ACCEPT
#iptables -A FORWARD -d 10.121.12.0/24 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -j DROP

echo 1 > /proc/sys/net/ipv4/ip_forward

This has been bugging me for about a week now. It was hard enough setting up this VPN to the VPC and I'm so close to having everything working. Any help would be much appreciated.

Regards

Paul.

[Lazydog]

First, stop mixing how you are filtering the traffic.
Either Filter by state, i.e., NEW,ESTABLISHED,RELATED or by connection but not both.
What I mean by connection is for example;
This is connection based.

iptables -A FORWARD -s 10.121.10.0/24 -j ACCEPT

This would be by STATE;

iptables -A FORWARD -s 10.121.10.0/24 -m state --state NEW  -j ACCEPT

If you are doing connection based then you don't need the ESTABLISHED,RELATED rules.

Now how many hosts are in the VPC?

I take it the following are to be individule hosts?

iptables -A FORWARD -s 169.254.254.2/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.1/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.6/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.5/30 -j ACCEPT

Individule hosts are a '/32' not '/30' and if they are to be individule hosts then you don't need the mask at all.
If you are looking for a range then you don't need to list each host.

Now the next question is are the hosts in 169.254.254.* to be able to access the firewall?
If not then you sould remove the INPUT rules for these hosts.

INPUT is for connecting to the device
FORWARD is for allowing the connection to pass through the device.

HERE is a tutorial for some reading if you'd like.

[rookiepaul]

Thanks for the reply.

Currently there is only 1 host in the VPC (10.121.12.4). The 169.254.254.x addresses are the IPSec tunnel alias addresses on the Debian gateway in the office and the virtual gateway in the VPC.

The VPC and the office subnets talk to each other fine. I literally just cannot get the VPC to access the Internet via my Debian gateway in the office. The Internet request packets come from the VPC and hit the Debian gateway but don't seem to go anywhere.

Pinging google.co.uk from the VPC instance (Debian gateway TCPDUMP):

zoovpcgw01:/etc/network/if-up.d# tcpdump -i eth1 host -n 173.194.37.104
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:25:48.467211 IP 10.121.12.4 > 173.194.37.104: ICMP echo request, id 512, seq 37898, length 40
11:25:53.612933 IP 10.121.12.4 > 173.194.37.104: ICMP echo request, id 512, seq 38154, length 40
11:25:59.111659 IP 10.121.12.4 > 173.194.37.104: ICMP echo request, id 512, seq 38410, length 40
11:26:04.610831 IP 10.121.12.4 > 173.194.37.104: ICMP echo request, id 512, seq 38666, length 40

I have been modding the iptables script since I posted and have cleaned up the 169.254.254.x rules but still doesn't work.

Latest iptables:

#!/bin/sh

PATH=/usr/sbin:/sbin:/bin:/usr/bin

#
# delete all existing rules.
#
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

#---------------#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 10.121.12.0/24 -j ACCEPT
iptables -A INPUT -s 10.121.10.0/24 -j ACCEPT
iptables -A INPUT -s 169.254.254.0/30 -j ACCEPT
iptables -A INPUT -s 169.254.254.4/30 -j ACCEPT
iptables -A INPUT -j DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.121.12.0/24 -j ACCEPT
iptables -A FORWARD -s 10.121.10.0/24 -j ACCEPT
iptables -A FORWARD -s 169.254.254.0/30 -j ACCEPT
iptables -A FORWARD -s 169.254.254.4/30 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -s 10.121.12.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 10.121.10.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 169.254.254.0/30 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 169.254.254.4/30 -j MASQUERADE
iptables -A FORWARD -j DROP
echo 1 > /proc/sys/net/ipv4/ip_forward

Many thanks.

[Lazydog]

What does your routing tables look like. That sounds more like the issue. Does google.com resolve for the people on then VPC? Do a trace to see where the packets are getting lost.

[rookiepaul]

All URL resolve. The DNS server is one of the office domain controllers. It's able to speak to it with no problems.

Routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.254.0   0.0.0.0         255.255.255.252 U     0      0        0 eth1
169.254.254.4   0.0.0.0         255.255.255.252 U     0      0        0 eth1
213.121.253.120 0.0.0.0         255.255.255.248 U     0      0        0 eth1
10.121.10.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         213.121.253.125 0.0.0.0         UG    0      0        0 eth1

The ping packets to google.co.uk hit eth1 on the debian gateway but then seem to go nowhere. Really stumped.

Thanks

Paul.

[Lazydog]

What do you get from

route -n

[rookiepaul]

That's the output above mate.

[Lazydog]

OK, I see the issue here now. I had to look at your rules again and you might have cleaned up the rules in general as I have said to do, but your rules are still IP based and not connection based. The reason everything is working internally is because you have all the IP Addresses covered. But the return traffic you don’t thus it is being dropped. In a nut shell you rules are saying if the packet is from one of the IP Addresses you have listed let it through. All other drop. You need to change your rules to be connection based using the NEW state flag. This will then place a record in the connection tracking DB so that return traffic is allowed to pass. See my first post on this thread as to what needs to be done.

Another question is do all these IP Addresses require access to the firewall/router or are they just passing through? If just passing through then your INPUT rules are not needed. The only IP should be the one that has to log onto the box for admin related working ONLY.

[rookiepaul]

I'm a bit confused mate. You're saying that my rules are dropping anything from an untrusted source. Which is fine. But if I set up one of my boxes in the office (10.121.10.0/24) to use the debian box as it's gateway it can access the Internet no worries. But a VPC box can't, and the rules are exactly the same for both the VPC and the office networks.

Is there a way I can just blanket accept everything to test whether it's a routing issue or a firewall issue? Alternatively maybe I'm missing what you're saying.

[Lazydog]

If you want to Blanket accept everything then the first rule of each chain would be

 iptables -A <Chain> -j ACCEPT

or you just should down the firewall.