TIL: bogus NAT
parent
120e8e610e
commit
2c81cf207c
@ -0,0 +1,26 @@
|
||||
Only NAT packets you can deliver responses for
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
|
||||
:slug: masquerade-with-filter
|
||||
:date: 2024-05-08
|
||||
:tags: linux
|
||||
:category: til
|
||||
:keywords: nat, nftables, network
|
||||
:lang: en
|
||||
:translation: false
|
||||
:status: published
|
||||
|
||||
When setting up a masquerading nat, it is worth considering masquerading only
|
||||
packets from known networks. That is, instead of rule like ``iifname eth-inside
|
||||
masquerade`` use something like ``iifname eth-inside ip saddr 198.51.100.0/24
|
||||
masquerade``.
|
||||
|
||||
I learned the hard way: my laptop in a masqueraded network picked a wrong
|
||||
source address from a subnet the router had no knowledge about. The outbound
|
||||
packets passed through right, but the responses came in, undergone translation,
|
||||
and since the destination was unknown to the router, it used the *default*
|
||||
route, sending the packet back to the ISP.
|
||||
|
||||
The result: IDS triggered by *many* packets from my router with source IP
|
||||
addresses from all around the Internet, all with destination to my private
|
||||
address. (The ISP was not happy about that.)
|
Loading…
Reference in New Issue