0

I use a WireGuard VPM to reversely connect to my home server via an external entry node. On that entry node, I try to add a firewall rule using ufw. Its purpose is to only allow routing to one and only one specific IP (10.0.0.6).

So the basic setup is:

10.0.0.1    entry node (publicly available, responsible for routing packets inside the VPN)
10.0.0.6    home server (should be reachable for any machine in the VPN)
10.0.0.13   any other peer (should not be reachable for other peers, therefor the ufw rule)

Routing packets via the entry node works fine, but the firewall rule does not deny other target IPs.

My setup looks like this:

user@host:~$ sudo ufw route allow in on wg0 out on wg0 to 10.0.0.6/32
Rule added

->

user@host:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
...
[firewall rules]
...

10.0.0.6 on wg0        ALLOW FWD   Anywhere on wg0  

(Note: I removed other rules. They are not related to routing, only ALLOW IN / LIMIT IN rules)

Above output clearly shows Default: .. deny (routed), while the following output claims "ACCEPT" policy in all chains.

user@host:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Surprisingly, the following command shows different:

user@host:~$ sudo iptables -L
Chain INPUT (policy DROP)
...        

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ufw-before-logging-forward  all  --  anywhere             anywhere            
ufw-before-forward  all  --  anywhere             anywhere            
ufw-after-forward  all  --  anywhere             anywhere            
ufw-after-logging-forward  all  --  anywhere             anywhere            
ufw-reject-forward  all  --  anywhere             anywhere            
ufw-track-forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
...

This unanswered question on askubuntu contains a comment from saiarcot895, who seems to have a related issue (it is where I found the idea to try the two preceding commands).

Whatever I've tried so far, I can still ping e.g. 10.0.0.13 from the home server.

user@home-server:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=58.0 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=51.7 ms

I would expect, however, that this ping package does not get routed, and therefor returns a timeout or similar.

My question is Is this expected behaviour, and if yes, how would I create the respective rule with ufw?

Weirdly enough, I could not find an answer in the far far internetwork. But this should be easy, so I dive once again into the ufw manpage. If you have any idea meanwhile, let me know!

3
  • Your question is confusing. Is your home server 10.0.0.6 or is that some other server? What makes you expect that ping 10.0.0.2 would be forwarded through the sever on which you've set up this ufw firewall? Try at least defining the structure of your network, which IP addresses belong to which severs, and give a specific example of what traffic you're trying to allow and disallow. Apr 26, 2021 at 19:09
  • Thank you for the comment. I do not understand it, tho. Nothing makes me expect that I can ping 10.0.0.2. I would expect to NOT be able to do so, as explained in the question. Also, yes, 10.0.0.6 is my home server. I may draw a nice graphic this week to show the setup, and may edit the question to make it easier to read without focusing for too long.
    – randmin
    Apr 27, 2021 at 20:45
  • Update: I added some lines to map the IPs to hosts, hopefully supporting the reader
    – randmin
    Apr 29, 2021 at 1:54

1 Answer 1

2

It's expected behavior. Try using something other than ping to test. For example, if you have a webserver running on port 80 of 10.0.0.13, try running curl 10.0.0.13 on your home server (10.0.0.6).

Your UFW command, ufw route allow in on wg0 out on wg0 to 10.0.0.6/32, is correct. It will allow all incoming packets sent to the host's wg0 interface that are destined for 10.0.0.6 to be forwarded out the wg0 interface to 10.0.0.6. UFW also automatically sets up a firewall rule that allows the reverse for already-established connections (ie forward packets back from 10.0.0.6 to the original source of the established connection).

UFW also always allows certain ICMP packets types (such as type 8, "echo request", used by ping requests) to be forwarded through all of the host's interfaces. So, regardless of any UFW rules you set, your entry node will forward packets from ping to any other hosts to which it can connect.

To stop UFW from forwarding (IPv4) ping packets by default, edit the /etc/ufw/before.rules file, and comment out (ie add a # to the start of) this line:

#-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

For ping over IPv6, edit the /etc/ufw/before6.rules file, and comment out these lines:

#-A ufw6-before-forward -p icmpv6 --icmpv6-type echo-request -j ACCEPT
#-A ufw6-before-forward -p icmpv6 --icmpv6-type echo-reply -j ACCEPT

Then restart UFW (eg sudo systemctl restart ufw).

Use sudo iptables-save | grep -i forward to check the iptables (IPv4) rules that now apply to your FORWARD chain. Before commenting out the above line, the output will look like this:

:FORWARD DROP [0:0]
:ufw-after-forward - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-reject-forward - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-track-forward - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-logging-forward - [0:0]
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-skip-to-policy-forward -j DROP
-A ufw-user-forward -d 10.0.0.6/32 -i wg0 -o wg0 -j ACCEPT

After commenting out the line and restarting UFW, the output should no longer list the -A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT rule.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .