I am using two routers in series and IPSEC traffic going through the second router which generated by the first router. That traffic puts a high load on the second router (GW). It won’t be accelerated and I can put plus 500 M/bit/s through it and it will hardly break out a sweat (fastrack) but 170 Mbit/s IPSEC will stress it. It is a IKEv2 connection and I tried with IPSEC policies disabled on router 2 (GW) but that made no difference.
I tried to use fasttrack for that exact IP-SEC traffic (portocol 50), despite that in connection tracking the connection is marked with “F” as being fasttracked it is not (Fasttrack counters not moving). Fasttrack should skip IP-SEC policies so that should not slow it down.
The strange thing is if I want to mark that traffic in Mangle it will not work when I only use New as trigger. It seems if the traffic is already examined before and so not New anymore.
Is there a way to have that IP-SEC traffic accelerated by Fasttracking or other means?
The IPsec transport traffic can only use plain ESP (protocol 50) if there is no NAT between the peers, which normally means that it can be only locally originated (outgoing) from your outer router (GW2) which has a public IP on its WAN. As fasttracking is only related to forwarded traffic, not incoming/outgoing, I don’t understand how such traffic can be marked with F in /ip firewall connection print.
If you have the IPsec SA terminated at the inner router, then its ESP traffic is forwarded by the outer router, and can be fasttracked there, but I don’t get how the peers could have negotiated use of ESP as the outer router is NATing the traffic from the inner one, unless you’ve put up the public IP of the outer router’s WAN also on some interface of the inner router, so that it would think that there is no NAT. Is that what you did? Because as your signature says that both routers do IKEv2, each of them would have to connect to another remote peer so that this could work.
Both router are doing IKEv2 on it’s own. On the inner router traffic is divided by PCC and connection-marked to the inner IKEv2 or to the GW router. In NAT the traffic marked, for the GW is source natted to to the GW router. There it is handled by the GW IKEv2 en/de-crypter.
Two streams are present in the GW router. First UDP/4500 plus IP-SEC/Protocol50 from inner and second the src-nat traffic, to be handled by IKEv2 en/de-crypter on the GW router.
Traffic from the inner goes trough the gateway of the inner to the GW router. In NAT (inner) I use a 172.x range and the routers self use 10.x. to connect to each other. The dynamic IKEv2 src-nat use 10.x as source and this traffic I can’t fasttrack in the GW.
I still cannot see how it is possible that the inner router uses ESP to communicate as you say it doesn’t have any public IP on itself. Can you show me the configuration?
It does not need a public address as the GW is providing that. It enters the GW router and looks for the address of the VPN provider not finding it there. Then it takes the door out and the internal source addres is replaced by the GW public address in NAT…darn then it could be is double natted. Going to check if trafic is being natted twice what I don’t expect.
Even if there is a single nat between the peers, the ESP gets encapsulated into UDP, as the NAT device cannot distinguish between received ESP for itself and ESP for the device behind it if they come from the same remote IP for both. There is no notion of ports in ESP, that’s why the encapsulation into UDP is used.
I found now the perpetrator and as it was indeed because of doing double NAT. When having to use double NAT I have to enable Nat traversal in IPSEC Profiles. This not being enabled, I got two separate streams on the GW from coming the inner. I was already asking myself why the IP-SEC was transporting the traffic instead of UDP/4500 despite it was a tunnel connection as stated in policies.
So, if one sees IP-SEC (protocol 50) coming from a other router downstream (routers/clients behind yours) then it is very wrong.
The processor load on the GW more than halved and so more time to encrypt it’s own traffic.
