It seems to give a 30% reduction to use NOTRACK in a IPSEC connection. The current client config in ROS has an option to set Prerouting or Output but the IP addresses used do not catch anything in RAW. It uses the internal addresses and not the addresses communicated to.
So I made an addresslist with the external IP numbers of my VPN provider and named it NoTrackIKEV.
On starting the IKEv2 connection I could not connect so I put an accept in RAW for anything from the VPN provider. Then I could start and once started I could disable that line in RAW again…till the next start. I have added !ipsec-esp to that line as protocol and now it will start and when started the ipsec-esp and port 4500 is not visible anymore in connection tracking.
I looked in the forum and wiki but not found the this configuration with IPSEC (IKEv2 / not NAT-T) and why do I have to kick-start it this way by excluding first traffic on port 4500 I assume?
addition: I don’t know if this has any bearing on it. This router is routed through an other router before reaching the Internet and that router also runs IKEv2 connections.
These are designed for another use case than the one you expect, it’s for the payload packets to be transported using IPsec. The original purpose of VPNs is to interconnect sites running on private addresses via public internet. In a typical case where there is only a default route in the router, which goes through a WAN with src-nat or masquerade, also packets towards those remote private networks get src-nat’ed, which makes them invisible for the policy. So to prevent this, you can use an accept rule before the src-nat or masquerade for packets towards the private networks if you need to use the stateful firewall, or you prevent them from being handled by connection tracking (which makes NAT handling impossible) if you don’t need to refer to connection-state in the firewall rules.
The idea to exclude the IPsec transport packets from connection tracking using the action=notrack to prevent them from being matched against the whole list of tracked connections never came to my mind. What exactly did you mean by
? If 30% less CPU load for the same payload throughput on IPsec, it is a really interesting result (but I’d expect that your connection list has to be really large to get such an impact, can you confirm that?)
However, this can add significant load to router’s CPU if there is a fair amount of tunnels and significant traffic on each tunnel.
Solution is to use IP/Firewall/Raw to bypass connection tracking, that way eliminating need of filter rules listed above and reducing load on CPU by approximately 30%.
Oh, OK. But that’s all still relevant to the traditional use of VPN, where it is desirable to avoid NAT. In the model where you get a dynamically assigned public address and you need that the connections which have to go via the tunnel are src-nated to that address, which I believe is your usage case with NordVPN, you must not disable connection tracking for that traffic, because the NAT handling is provided by connection tracking. So you must use other means to prevent those connections from getting fasttracked, but they must stay tracked in order to be nated.
I just concluded my short test and did not find noticeable difference between tracking and notracking.
I am notracking the outside of the IPSEC connection/tunnel and traffic inside the tunnel is not Fasttrack-ed nor Notrack-ed.
Using two routers in series increases the speed to between 200 and 300MBit/s (more speed up than down). Dumping L2TP/IPSEC and switching only to IKEv2 VPN increased the speed also.
Maybe you can disable the tracking of the “outside” IPsec traffic and keep the tracking of the tunneled connections themselves?
I’m no expert on this as:
I always use explicit tunnels protected with IPsec transport. I’m sure it works like the above there
I don’t waste my time with (fast)tracking yes/no to improve performance, I just buy the router that can do the task at hand without this