Score:1

Can't get linux iptables masquerade work

sv flag

Similar questions that don't answer the problem:
https://stackoverflow.com/questions/16038852/iptables-to-modify-source-ip-nothing-in-postrouting-chain-log

In my Linux MASQUERADE is not replacing the Source IP

My setup is as follows:

  1. On all Nodes (sysctl net.ipv4.ip_forward: 1)
  2. On all Nodes (Iptables with ACCEPT policies on all chains)
  3. PC3 is a Linux server with 2 dockers containers, being them, PC1 and PC2.

IMPORTANT: I've already tested creating virtual machines, and the problem remains :(

PC1:
eth0 (02:42:c0:a8:00:65):
IPv4: 192.168.0.101
Gateway: 192.168.0.102

Route Rules:
ip route add default via 192.168.0.102 dev eth0

ip -4 -br addr; ip route:
lo               UNKNOWN        127.0.0.1/8 
eth0@if70        UP             192.168.0.101/16 
default via 192.168.0.102 dev eth0 
192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.0.10

PC2:
eht0: (02:42:c0:a8:00:66):
IPv4:  192.168.0.102
Gateway: 192.168.0.1

Route Rules:
ip route add default via 192.168.0.1 dev eth0

ip -4 -br addr; ip route:
lo               UNKNOWN        127.0.0.1/8 
eth0@if72        UP             192.168.0.102/16 
default via 192.168.0.1 dev eth0 
192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.0.102

PC3:
br-630e93c20055 (02:42:4c:47:1f:4c): 
IPv4: 192.168.0.1

enp0s10 (02:00:17:02:3c:eb):
IPv4: 10.0.0.192
Gateway: 10.0.0.1
PS: This gateway (10.0.0.1) is the router 

ip -4 -br addr; ip route:
lo               UNKNOWN        127.0.0.1/8
enp0s10          UP             10.0.0.192/24
docker0          UP             172.17.0.1/16
br-630e93c20055  UP             192.168.0.1/16
default via 10.0.0.1 dev enp0s10 proto dhcp src 10.0.0.192 metric 100
10.0.0.0/24 dev enp0s10 proto kernel scope link src 10.0.0.192 metric 100
169.254.0.0/16 dev enp0s10 proto dhcp scope link src 10.0.0.192 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.0.0/16 dev br-630e93c20055 proto kernel scope link src 192.168.0.1
192.168.0.101 via 10.0.0.1 dev enp0s10 src 10.0.0.192

Iptables Rules:
Chain POSTROUTING (policy ACCEPT)
target      prot    opt   source               destination
MASQUERADE  all     --    192.168.0.0/16       anywhere

iptables-save -c:
https://pastebin.com/BPRBKymM

PS:
I already tried the following:
iptables -t nat -A POSTROUTING -s 192.168.0.101/32 -j SNAT --to-source 10.0.0.192

This is Capture PCAP from PC2

https://app.packetsafari.com/analyze/l/dlKtVooBW6-oT3TQ8m8c

Interface: eth0

This is Capture PCAP from PC3

https://app.packetsafari.com/analyze/l/fFKwVooBW6-oT3TQg287

Interface: All Interfaces

What I want the source IP to be 10.0.0.192 in Wireshark, and the PC1 machine to access the internet.

My idea is the following (instead of the default):

  1. PC1 (192.168.0.101) sends a packet (ping) to 1.1.1.1
  2. PC2 (192.168.0.102) redirects this packet to 192.168.0.1 (FORWARD) without changing the origin to 192.168.0.102, that is, the origin remains 192.168.0.101
  3. PC3 (192.168.0.1/br-630e93c20055) receives this packet and does the SNAT (or MASQUERADE) setting the source IP to 10.0.0.192/enp0s10 and forwards the packet to the router.
  4. Router (10.0.0.1/LAN) does SNAT and forwards packet to IP 1.1.1.1
  5. Receives a response, and forwards it to PC3: 10.0.0.192
  6. PC3 will check internal NAT table and forward to 192.168.0.101
  7. PC1 will receive the package and everyone will be happy.

Unsuccessful attempts:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0

net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.eth0.send_redirects = 1

net.ipv4.conf.all.accept_source_route = 1
net.ipv4.conf.default.accept_source_route = 1
net.ipv4.conf.eth0.accept_source_route = 1

net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1

net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.eth0.log_martians = 1

I want this routing problem presented via step-by-step in the description to be corrected, I believe it is not a Linux defect but my lack of experience with it.

I apologize for anything, but I'm a novice user.

A.B avatar
cl flag
A.B
Can you instead give the output of this command so we can be 100% sure of the iptables rules in place? `iptables-save -c`. And about the capture: it could be easier to use tcpdump or tshark so it's done as text and included in the body of the question. You should also specify on what interface(s) the capture was done, or else include the Ethernet layer (`-e` with tcpdump) and relevant information from 3 systems (`ip -br link`; and while at it: `ip -4 -br addr; ip route`).
Gabriel avatar
sv flag
@A.B I put the requested information, only the capture I shared a link because I believe it is easier to view.
A.B avatar
cl flag
A.B
So it's about Docker: PC1 and PC2 are not standard systems but Docker containers. The main part: `iptables-save -c` is hidden in the tiny link that will disappear someday. You'll have to rework your question to expose what matters: it's about Docker containers. Whatever usually works manually gets interference from Docker which should be the tool to talk about and where a fix (in the way to run containers) should happen. I won't go further.
Gabriel avatar
sv flag
@A.B I've already tested creating virtual machines, and the problem remains :(
I sit in a Tesla and translated this thread with Ai:

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.