Compare commits
2 Commits
120e8e610e
...
8036b2c757
Author | SHA1 | Date |
---|---|---|
LEdoian | 8036b2c757 | 6 months ago |
LEdoian | 2c81cf207c | 6 months ago |
@ -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