Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Firewall POSTROUTING problem

29 views
Skip to first unread message

Alain D D Williams

unread,
Aug 11, 2021, 5:10:04 PM8/11/21
to
Hi,

I have problems getting POSTROUTING to work on a Debian 10 box.

Setup:

INTERNET ... Broadband modem 192.168.108.1

Network internal to the Debian box for virtual machines 10.239.239.0/24

Debian has address 192.168.108.2 (interface enp3s0) and 10.239.239.254 (interface br0)

Processes on Debian 10 can talk to the Internet

Processes on virtual machines (eg 10.239.239.23) can talk to the Debian machine
(ie 192.168.108.2) on which they are hosted.

If on 10.239.239.23 I ping the BBC (212.58.249.145) and look with a packet
sniffer on the BB modem I see outgoing addresses 10.239.239.23

This should not happen. I am running an iptables firewall that should fix this
with the rule below:

iptables -t nat -A POSTROUTING -s 10.239.239.0/24 -j SNAT --to-source 192.168.108.2

I have tried variations like:
iptables -t nat -A POSTROUTING -o enp3s0 -j SNAT --to-source 192.168.108.2


It is as if the POSTROUTING rule is being ignored.

This seems to be confirmed by the output below which shows that 0 packets have
been through POSTROUTING.

Can anyone shed any light on this ?

Thanks in advance



# iptables -L -n -t nat -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * * 10.239.239.0/24 0.0.0.0/0 to:192.168.108.2

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination


--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

deloptes

unread,
Aug 11, 2021, 5:40:05 PM8/11/21
to
Alain D D Williams wrote:

> Hi,
>
> I have problems getting POSTROUTING to work on a Debian 10 box.
>
> Setup:
>
> INTERNET ... Broadband modem 192.168.108.1
>
> Network internal to the Debian box for virtual machines 10.239.239.0/24
>
> Debian has address 192.168.108.2 (interface enp3s0) and 10.239.239.254
> (interface br0)
>
> Processes on Debian 10 can talk to the Internet
>
> Processes on virtual machines (eg 10.239.239.23) can talk to the Debian
> machine (ie 192.168.108.2) on which they are hosted.
>
> If on 10.239.239.23 I ping the BBC (212.58.249.145) and look with a packet
> sniffer on the BB modem I see outgoing addresses 10.239.239.23
>
> This should not happen. I am running an iptables firewall that should fix
> this with the rule below:
>
> iptables -t nat -A POSTROUTING -s 10.239.239.0/24 -j SNAT --to-source
> 192.168.108.2
>
> I have tried variations like:
> iptables -t nat -A POSTROUTING -o enp3s0 -j SNAT --to-source 192.168.108.2
>
>
> It is as if the POSTROUTING rule is being ignored.
>
> This seems to be confirmed by the output below which shows that 0 packets
> have been through POSTROUTING.
>
> Can anyone shed any light on this ?

I remember it was not only the POSTROUTING. May be I am wrong, but I think
FORWARD and OUTPUT is important.
I also wonder why you are mixing up the -s and --to-source. You should be
using the local address for -s and --to-source the translation (the
outgoing addresses 10.239.239.23)

I later switched to shorewall and since it is doing the iptables rules for
me, so now I just have to put some values in a config and would have
something like

# iptables-save | grep eth0
:eth0_masq - [0:0]
-A PREROUTING -i eth0 -j net_dnat
-A POSTROUTING -o eth0 -j eth0_masq
-A eth0_masq -s 192.168.xxx.0/24 -j SNAT --to-source 10.0.xxx.1
-A INPUT -i eth0 -j net-fw
-A FORWARD -i eth0 -j net_frwd
-A OUTPUT -o eth0 -j ACCEPT
-A dmz_frwd -o eth0 -j dmz-net
-A loc_frwd -o eth0 -j ACCEPT
-A vpn_frwd -o eth0 -j vpn-net


--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

Alain D D Williams

unread,
Aug 11, 2021, 5:50:05 PM8/11/21
to
On Wed, Aug 11, 2021 at 11:32:51PM +0200, deloptes wrote:

> I remember it was not only the POSTROUTING. May be I am wrong, but I think
> FORWARD and OUTPUT is important.
> I also wonder why you are mixing up the -s and --to-source. You should be
> using the local address for -s and --to-source the translation (the
> outgoing addresses 10.239.239.23)

This says that anything with a source address 10.239.239.0/24 (ie virtual
machine) will have the source address changed to 192.168.108.2; this is so that
the BB modem does another NAT setting the source address to my external IP
address.

While I am debugging this, to avoid complication, I have set:

iptables -A FORWARD -j ACCEPT

and this is not a problem ... evidence is outgoing packets with source address
10.239.239.23

deloptes

unread,
Aug 11, 2021, 6:00:06 PM8/11/21
to
Alain D D Williams wrote:

> iptables -A FORWARD -j ACCEPT
>

and the OUTPUT?

> and this is not a problem ... evidence is outgoing packets with source
> address 10.239.239.23

ah, ok, I misinterpreted it.

Alain D D Williams

unread,
Aug 11, 2021, 6:10:05 PM8/11/21
to
On Wed, Aug 11, 2021 at 11:50:30PM +0200, deloptes wrote:
> Alain D D Williams wrote:
>
> > iptables -A FORWARD -j ACCEPT
> >
>
> and the OUTPUT?

OUTOUT is also ACCEPT, however this is not, I think, important as the packets
come from 10.239.239.23 (via br0) and go to the Internet - thus FORWARD is what
is important. Anyway: I see (on the modem) the packets with source 10.239.239.23

> > and this is not a problem ... evidence is outgoing packets with source
> > address 10.239.239.23
>
> ah, ok, I misinterpreted it.

The important stuff from ifconfig is:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.239.239.254 netmask 255.255.255.0 broadcast 10.239.239.255
inet6 fe80::7ca1:36ff:fe12:7402 prefixlen 64 scopeid 0x20<link>
ether ee:3c:27:eb:c0:4f txqueuelen 1000 (Ethernet)
RX packets 31632 bytes 2596968 (2.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2065 bytes 374487 (365.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.108.2 netmask 255.255.255.0 broadcast 192.168.108.255
inet6 2001:4d48:ad51:2f00::2:2 prefixlen 112 scopeid 0x0<global>
inet6 fe80::922b:34ff:fe12:6470 prefixlen 64 scopeid 0x20<link>
ether 90:2b:34:12:64:70 txqueuelen 1000 (Ethernet)
RX packets 922014 bytes 240006341 (228.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 562616 bytes 80027668 (76.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

IL Ka

unread,
Aug 11, 2021, 6:30:05 PM8/11/21
to


> > iptables -A FORWARD -j ACCEPT

Are you sure your packets are forwarded via netfilter?
Try to disable forwarding (with sysctl) or change rulte to -j DROP and check traffic with sniffer (no packet should be forwarded from virt machine to the Internet)



 

Alain D D Williams

unread,
Aug 11, 2021, 6:50:04 PM8/11/21
to
It now works all of a sudden .... I am scratching my head to see what I have
changed. The only thing is rebooting the virtual machine that I was testing
from. I cannot see that that should have made a difference. I was changing the
firewall ...

Anyway: thanks for now, I am sorry if I have wasted anyone's time :-(

Lucas Castro

unread,
Aug 12, 2021, 1:30:05 PM8/12/21
to
The steps to get routing working on GNU/Linux


check ip_forward is enabled

cat /proc/sys/net/ipv4/ip_forward - it must be 1


In your case, your outgoing is 192.168.108.2 on enp3s0

and your lan network is 10.239.239.254

so the forwarding nat rule should be

iptables -t nat -A POSTROUTING  -s 10.239.239.0/24 -o enp3s0 -j SNAT
--to  192.168.108.2

No need for INPUT/OUTPUT rules to forward packts, only FORWARD rules


iptables -A FORWARD -s 10.239.239.0/24 -i br0 -o  enp3s0 -m state
--state NEW -j ACCEPT

To accept the incoming packts for related connections.

iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT


you need to be sure there is default route on the router, or trick the
route using 'ip rule'

but check if the router is set any default route

'ip route list' or 'ip route list table default'

---
Lucas Castro
0 new messages