0

I have what appears to be a unique situation that I am surprised is unique as it's common to most cablemodem implementations...

I need to masquerade to the dynamic public address provided by $CABLECO on my WAN interface. However, I also need to be able to manage the cable modem by it's local (192.168.100.1/24) address which means I also need a static 192.168.100.0/24 address that isn't .1 (I'm using .10) on the WAN interface and a route to the cablemodem's address that isn't SNATted.

I have all of that working mostly, except that for reasons not entirely clear to me, sometimes the masquerade will SNAT the other traffic to the 192.168.100.10 instead of the address provided via DHCP from $CABLECO.

This wreaks havoc with my internet connectivity and I haven't found a solution short of either removing the 192.168.100.x address from the interface or using SNAT and hard-coding the DHCP address into nftables. The former means I can't manage the cable modem through its embedded web server (or any other method). The latter means that if $CABLECO changes things, my internet access breaks until I manually reconfigure nftables to the new address.

Neither of these seems desirable.

Is there any way to influence the SNAT Source Address Selection process in nftables when masquerading? If not, is there any way to SNAT to a dynamic address while excluding other interface addresses from SNAT consideration?

Improve this question
3
  • 1
    This will be excruciatingly painful without your nft config file. If you have static WAN IPs that you do not want us to see, just use 1.2.3.4 or something. There may be someone who can say "do this", but I think providing what you have would help immensely. Commented Oct 9 at 19:44
  • I think setting the scope of 192.168.100.10 to link would prevent it from being used for masquerade. If it doesn't, you may also consider using a MACVLAN for it. Commented Oct 10 at 11:06
  • (Maybe IPVLAN is sufficient and a better choice. I don't know much about it. Or if it's an "external" bridge enslaved with a physical NIC, a veth pair should do as well -- one enslaved to the bridge and one for the extra IP.) Commented Oct 10 at 11:25

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.