0

I am trying to use Ubuntu as a router of a kind by limiting a computer on my private network to what it can connect to on the internet.

The Ubuntu box has two NICs, one is internet facing (enp0s3), one is facing this single private PC (enp0s8).

To start with, I wanted to see if I could just allow DNS from the private box through the Ubuntu. I followed some instructions to add some "route allow" rules such as it results in:

ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), deny (outgoing), allow (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
8.8.8.8 on enp0s3          ALLOW FWD   Anywhere on enp0s8        
8.8.4.4 on enp0s3          ALLOW FWD   Anywhere on enp0s8        
10.0.1.5 on enp0s8         ALLOW FWD   Anywhere on enp0s3   

10.0.1.5 is my private PC. Using Wireshark I can see DNS requests being made on both enp0s3 and enp0s8, but the ones on enp0s3 have no reply.

So after a bit more reading, I found I needed to set up NAT and masquerading, so I put the following into rules.before:

# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0 - Change to match you out-interface
-A POSTROUTING -s 10.0.1.0/24 -o enp0s3 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT

This worked - but too well. Now all traffic is getting out and returned to my private PC, the default deny outgoing and the other UFW rules all seem to be bypassed.

So my question is simple - I want the private PC to get connectivity through Ubuntu such as the NAT provided, but with the outgoing restrictions as I thought I configured initially using the ufw command lines. Is there a way I get can get the UFW rules to somehow apply after the NAT does its thing?

TIA.

Here is the full before.rules file. My only change was the NAT table rules:

#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#

# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0 - Change to match you out-interface
-A POSTROUTING -s 10.0.1.0/24 -o enp0s3 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT


# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT
  • I think we might need to see you entire iptables rule set to determine what is going on. UFW generated iptables are difficult to follow. I run my main Ubuntu gateway/router/firewall with iptables directly, and wouldn't use UFW for such a task. Regardless of where you entered the rule, the NAT POSTROUTING chain will be the last one traversed. – Doug Smythies Jun 15 at 14:41
  • @DougSmythies I added the full before.rules file. The only change I made to the default is the NAT stuff. I have not modified any other iptables files so they are default as well, I have just run some ufw commands as shown originally. – aaa90210 Jun 15 at 20:59
  • Yes, but without the final resulting, and total, iptables rule set, we can not trace the packet flow. By the way, observing the packet counters can help with debugging. Post the outputs for sudo iptables -v -x -n -L and sudo iptables -t nat -v -x -n -L. – Doug Smythies Jun 15 at 21:11
0

It seems that routing/forwarding rules are completely separate to normal firewall rules. I move the NAT stuff to after.rules, and changed the default rule for "routed" traffic to "deny". It seems that POSTROUTING occurs after the default deny rule is applied - so if something is denied by the default rule, it won't be nat routed out. It is possible to add user rules of course (of the kind "ufw route allow ...") and they can permit traffic before the default deny is applied, and that will then be routed out as expected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.