Score:1

ip forward to another interface with ufw doesn't work

pk flag

I'm trying to setup an IP forward. Cannot manage to make it work. The goal is to receive a connection on interface1 (IP on this interface is 192.168.101.3) port 4443, and send it through interface2 to IP 192.168.4.5 (dest IP) port 4443.

  • I enabled "net.ipv4.ip_forward = 1" in /etc/sysctl.conf
  • setted DEFAULT_FORWARD_POLICY="ACCEPT" in /etc/default/ufw
  • added that to /etc/ufw/before.rules (from various tutorials):
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 4443 -j DNAT --to-destination 192.168.4.5:4443
-A POSTROUTING -o interface2 -j MASQUERADE
COMMIT

I still cannot connect with "nc 192.168.101.3 4443"

  1. Do you see anything wrong?
  2. How does ufw knows what interface to forward to if -o cannot be specified in DNAT? Won't it try to forward to 192.168.4.5:4443 on interface1?

edit:

192.168.101.1(computer 1) -> (192.168.101.3, 192.168.4.1)(computer 2) -> 192.168.4.5(computer 3)

The best I can get right now is this in the log

[ 1177.553749] [UFW AUDIT] IN= OUT=enp6s0 SRC=192.168.101.3 DST=192.168.101.1 LEN=88 TOS=0x00 PREC=0xC0 TTL=64 ID=62781 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.101.1 DST=192.168.4.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=13975 DF PROTO=TCP SPT=60720 DPT=4445 WINDOW=64240 RES=0x00 SYN URGP=0 ]

So if I understand correctly, the port 4443 on 192.168.4.5 is unreachable so 192.168.101.3 sends back an ICMP error packet back to 192.168.101.1 (the machine I'm connecting from with nc). Which is weird because if I try to connect with nc directly from 192.168.101.3 it works fine...

Doug Smythies avatar
gn flag
I do not see anything wrong, but I would specify the input interface for your PREROUTING command: `-A PREROUTING -p tcp -i interface1 --dport 4443 -j DNAT --to-destination 192.168.4.5:4443`. The system should know that the 192.168.4.0 sub-net is on interface2, via its ip address and the routing table. We might need to see things within the context of the overall iptables rule set, `sudo iptables -xvnL` and `sudo iptables -t nat -xvnL`, although ufw generated rules are difficult to read and follow.
pk flag
Hey doug, thanks for your comment. Here you go https://pastebin.com/26YVtdes, https://pastebin.com/UNSypVxE. (switched port to 4445, didn't help) Edited the post for more details.
Doug Smythies avatar
gn flag
Actually, I think you need a FORWARD rule added in the LIBVIRT_FWI chain. Add as the first or second rule, before the REJECT rule, one to accept packets with destination port 4445. (I'll come back with syntax later).
Doug Smythies avatar
gn flag
untested suggested needed rules, also adding logging: `sudo iptables -I LIBVIRT_FWI 1 -i enp6s0 -o virbr0 -p tcp --dport 4445 -d 192.168.4.5 -m state --state NEW -j LOG --log-prefix "PFNEW:" --log-level info` and `sudo iptables -I LIBVIRT_FWI 2 -i enp6s0 -o virbr0 -p tcp --dport 4445 -d 192.168.4.5 -m state --state NEW -j ACCEPT`.
pk flag
Hey sorry for the delay, thanks a lot that's amazing!
Score:0
pk flag

As said by Doug in the comments the problem was coming from libvirt messing up with iptables.

sudo iptables -I LIBVIRT_FWI 1 -i enp6s0 -o virbr0 -p tcp --dport 4445 -d 192.168.4.5 -m state --state NEW -j LOG --log-prefix "PFNEW:" --log-level info

sudo iptables -I LIBVIRT_FWI 2 -i enp6s0 -o virbr0 -p tcp --dport 4445 -d 192.168.4.5 -m state --state NEW -j ACCEPT

should solve the problem. Using a bridged connection is indeed another solution.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.