blog:linux:nftables_demystifying_ipsec_expressions
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
blog:linux:nftables_demystifying_ipsec_expressions [2022-02-06] – Added kernel tag Andrej Stender | blog:linux:nftables_demystifying_ipsec_expressions [2022-08-07] (current) – activated TOC Andrej Stender | ||
---|---|---|---|
Line 4: | Line 4: | ||
date created = 2022-01-30 | date created = 2022-01-30 | ||
~~ | ~~ | ||
- | |||
- | ~~NOTOC~~ | ||
In this article I like to take a look at the expressions provided by Nftables for matching IPsec-related network packets. The common situation is that you need to distinguish packets from normal traffic, which either have been received through a VPN tunnel and already have been decrypted or packets which are to be sent out on a VPN tunnel, but have not been encrypted yet. Those kind of packets can be matched by these expressions within packet filtering rules. I'll explain how these expressions work, what they use as back-end, what their limitations are and how you can use them to get your intended behavior. Further, I take a short glimpse at the Iptables equivalent of these expressions. | In this article I like to take a look at the expressions provided by Nftables for matching IPsec-related network packets. The common situation is that you need to distinguish packets from normal traffic, which either have been received through a VPN tunnel and already have been decrypted or packets which are to be sent out on a VPN tunnel, but have not been encrypted yet. Those kind of packets can be matched by these expressions within packet filtering rules. I'll explain how these expressions work, what they use as back-end, what their limitations are and how you can use them to get your intended behavior. Further, I take a short glimpse at the Iptables equivalent of these expressions. | ||
Line 18: | Line 16: | ||
if your system is the endpoint of an IPsec-based VPN tunnel, then it is essential to be able to distinguish between VPN and non-VPN traffic. While it is rather trivial to identify already/ | if your system is the endpoint of an IPsec-based VPN tunnel, then it is essential to be able to distinguish between VPN and non-VPN traffic. While it is rather trivial to identify already/ | ||
You could identify those packets in a rather crude way, e.g. by filtering according to the source/ | You could identify those packets in a rather crude way, e.g. by filtering according to the source/ | ||
- | packet actually will be or has been processed by IPsec at all. Further, information like the CIDR notation of the peer subnet address often is dynamic data resulting from an IKE handshake. Thus, you might not | + | packet actually will be or has been processed by IPsec. Further, information like the CIDR notation of the peer subnet address often is dynamic data resulting from an IKE handshake. Thus, you might not |
know it in advance and even if you do, it's a rather bad idea to statically hack it into your packet filtering rules, because it might change. Luckily the // | know it in advance and even if you do, it's a rather bad idea to statically hack it into your packet filtering rules, because it might change. Luckily the // | ||
One other way which simplifies distinction are so-called // | One other way which simplifies distinction are so-called // | ||
Line 152: | Line 150: | ||
</ | </ | ||
- | In a real world setup you should make use of the strongSwan '' | + | In a real world setup you should make use of the strongSwan '' |
===== Iptables expressions ===== | ===== Iptables expressions ===== | ||
Line 176: | Line 174: | ||
* [[https:// | * [[https:// | ||
- | //published 2022-01-30//, | + | //published 2022-01-30//, |
blog/linux/nftables_demystifying_ipsec_expressions.1644132259.txt.gz · Last modified: 2022-02-06 by Andrej Stender