Thermalcircle.de

climbing the thermals

User Tools

Site Tools

blog:linux:nftables_demystifying_ipsec_expressions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
blog:linux:nftables_demystifying_ipsec_expressions [2022-01-30] – created Andrej Stenderblog:linux:nftables_demystifying_ipsec_expressions [2022-08-07] (current) – activated TOC Andrej Stender
Line 1: Line 1:
-{{tag>linux netfilter nftables iptables ipsec strongswan xfrm}}+{{tag>linux kernel netfilter nftables iptables ipsec strongswan xfrm}}
 ====== Nftables - Demystifying IPsec expressions ====== ====== Nftables - Demystifying IPsec expressions ======
 ~~META: ~~META:
 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/still encrypted network packets by matching for the ESP protocol or for UDP port 4500 in case of Nat-traversal, it is not so trivial to identify packets which already have been decrypted or have not been encrypted yet. The latter kind of packets just look like any other traffic. 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/still encrypted network packets by matching for the ESP protocol or for UDP port 4500 in case of Nat-traversal, it is not so trivial to identify packets which already have been decrypted or have not been encrypted yet. The latter kind of packets just look like any other traffic.
 You could identify those packets in a rather crude way, e.g. by filtering according to the source/target IP address of a packet in case you know the subnet(s) of the VPN peer((I did this in my previous article, because it served perfectly as a simple example.)). However, that does not check at all whether the You could identify those packets in a rather crude way, e.g. by filtering according to the source/target IP address of a packet in case you know the subnet(s) of the VPN peer((I did this in my previous article, because it served perfectly as a simple example.)). However, that does not check at all whether the
-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 //strongSwan// IKE implementation provides a plugin with a hook script named ''_updown'', which is called when the VPN tunnel either goes up or down. This script has access to such dynamic data and you can place commands to add/remove your dynamic packet filtering rules in there((The default version of that script, ''/usr/lib/ipsec/_updown'', already places Iptables rules with IPsec expressions like the ones I am explaining here. However, an Nftables solution there is still missing and even if it wouldn't... who can assure that those rules fit perfectly in the concept of your potentially already existing Iptables/Nftables ruleset? Usually they do not, so in reality you might nearly always need to create your own version of that script... but that's a topic for another article... if I find time to write it.)). 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 //strongSwan// IKE implementation provides a plugin with a hook script named ''_updown'', which is called when the VPN tunnel either goes up or down. This script has access to such dynamic data and you can place commands to add/remove your dynamic packet filtering rules in there((The default version of that script, ''/usr/lib/ipsec/_updown'', already places Iptables rules with IPsec expressions like the ones I am explaining here. However, an Nftables solution there is still missing and even if it wouldn't... who can assure that those rules fit perfectly in the concept of your potentially already existing Iptables/Nftables ruleset? Usually they do not, so in reality you might nearly always need to create your own version of that script... but that's a topic for another article... if I find time to write it.)).
 One other way which simplifies distinction are so-called //route-based// VPN setups, which use virtual network interfaces. In case of IPsec those are either //vti// or //xfrm// interfaces. One other way which simplifies distinction are so-called //route-based// VPN setups, which use virtual network interfaces. In case of IPsec those are either //vti// or //xfrm// interfaces.
Line 152: Line 150:
 </code> </code>
  
-In a real world setup you should make use of the strongSwan ''_updown'' script, which has access to the ''requid'' value, to dynamically add and remove Nftables rules containing IPsec expressions on VPN tunnel build-up and teardown. Adding the ''reqid'' value statically as I did here, after obtaining it from the output of the ''ip xfrm state'' command, is not a wise idea, because the value could change on every successive IKE handshake. I'll try to cover that in a possible future article.+In a real world setup you should make use of the strongSwan ''_updown'' script, which has access to the ''reqid'' value, to dynamically add and remove Nftables rules containing IPsec expressions on VPN tunnel build-up and teardown. Adding the ''reqid'' value statically as I did here, after obtaining it from the output of the ''ip xfrm state'' command, is not a wise idea, because the value could change on every successive IKE handshake. I'll try to cover that in a possible future article.
  
 ===== Iptables expressions ===== ===== Iptables expressions =====
Line 176: Line 174:
   * [[https://ipset.netfilter.org/iptables-extensions.man.html|man iptables-extensions(8)]]   * [[https://ipset.netfilter.org/iptables-extensions.man.html|man iptables-extensions(8)]]
  
-//published 2022-01-30//, //last modified 2022-01-30//+//published 2022-01-30//, //last modified 2022-08-07//
  
  
  
blog/linux/nftables_demystifying_ipsec_expressions.1643555910.txt.gz · Last modified: 2022-01-30 by Andrej Stender