IkeV2 passthrough



  • Hi there,

    I am in the process of replacing a cisco router with PFsense (running on a VM) but have a problem. I have a server 2012 R2 vpn server that does ikev2 vpn's for mobile clients. With the cisco this works fine, UDP 500 and 4500 forwarded to the VPN server.

    So I added nat rules for the pfsense box as well:

    WAN1  ESP  *  *  WAN1 address  *  192.168.0.6  *
    WAN1  UDP  *  *  WAN1 address  500 (ISAKMP)  192.168.0.6  500 (ISAKMP)
    WAN1  UDP  *  *  WAN1 address  4500 (IPsec NAT-T)  192.168.0.6  4500 (IPsec NAT-T)

    But no luck, the clients do reach the server but I get a negotiation timeout in the event log on the Windows server.

    Any idea what I am missing here ?


  • Rebel Alliance Developer Netgate

    That all looks good. You may need to make sure you have outbound NAT doing static port for outbound UDP traffic from the server, just in case that causes some issues with connections going back the other way.



  • Thanks for your response.

    So currently PFsense is at auto outbound nat with these (see attachment).

    I have set it to manual and created an additional rule for port 4500 (see attachment) still no luck.

    Looking at the states the following is shown:

    LAN udp REMOTEPEER:4500 <- 192.168.0.6:4500 MULTIPLE:MULTIPLE 
    WAN1 udp PFSENSEWAN:16748 (192.168.0.6:4500) -> REMOTEPEER:4500 SINGLE:NO_TRAFFIC 
    WAN1 udp 192.168.0.6:500 (PFSENSEWAN:500) <- REMOTEPEER:500 SINGLE:MULTIPLE 
    LAN udp REMOTEPEER:500 -> 192.168.0.6:500 MULTIPLE:SINGLE 
    WAN1 udp 192.168.0.6:4500 (PFSENSEWAN:4500) <- REMOTEPEER:4500 SINGLE:MULTIPLE

    ![pfsense outbound.PNG](/public/imported_attachments/1/pfsense outbound.PNG)
    ![pfsense outbound.PNG_thumb](/public/imported_attachments/1/pfsense outbound.PNG_thumb)
    ![pfsense outbound 2.PNG](/public/imported_attachments/1/pfsense outbound 2.PNG)
    ![pfsense outbound 2.PNG_thumb](/public/imported_attachments/1/pfsense outbound 2.PNG_thumb)



  • Ok, I tried a static outbound nat for the VPN server, again no luck.

    I also noticed that I cannot make ikev2 VPN connections from inside the network (with a client) to vpn servers outside that I know work fine.

    Once I put the Cisco RV042G in front of the clients, these VPN's work fine, AND incomming vpn connections to my vpn server also start working.

    I really hope someone on here can point me in the right direction, as this is a clear deal breaker, and I really wanted to use PFsense as replacement for the Cisco router, but without this working properly, I cannot take that step.



  • You don't want static port on 500 nor 4500 in that scenario. Stick with automatic outbound NAT. Reset all states after changing back to automatic outbound.

    The states you pasted earlier, the SINGLE:NO_TRAFFIC means a packet was sent out, and nothing was received in reply.



  • I am a bit confused, as the auto nat displays a static NAT for 500 (see my first screenshot). Are you saying I need to leave that there, as I tried doing that numerous times, even with reboots just to be sure. Or should I set it to manual, but delete the two auto rules created for static port 500 ?

    I know that the vpn client does get to the server, but I get eventid 20255: CoId={D8B368FA-2011-1D6B-41E2-BE54743E6C1D}: The following error occurred in the Point to Point Protocol module on port: VPN2-125, UserName: <unauthenticated user="">. Negotiation timed out

    each connect request leads to the exact same error.

    And as said, I am also unable to connect to ikev2 VPN's back at work using a client behind pfsense, even with the changes I just made.

    In any case, I tried both options, and both with the same result, I am not able to connect either to the VPN server from outside using IKEv2 nor am I able to connect using IKEv2 to outside VPN servers.

    Boy I would like to know which combination does make it work :)

    If it makes any difference, the VPN server assigns IPv4 addresses in the same range as the LAN (192.168.0.x) and assigns a Ipv6 prefix that is different from the main lan's 64 prefix. I route the ipv6 packages via the pfsense (which works if I connect to the vpn from the inside).

    In any case, after changing outbound nat and removing any "500" static rules (two rules are left) this is what I am getting:

    LAN udp 178.231.53.65:4500 <- 192.168.0.6:4500 MULTIPLE:MULTIPLE 
    WAN1 udp 192.168.0.6:500 (83.162.230.231:500) <- 178.231.53.65:500 MULTIPLE:MULTIPLE 
    LAN udp 178.231.53.65:500 -> 192.168.0.6:500 MULTIPLE:MULTIPLE 
    WAN1 udp 192.168.0.6:4500 (83.162.230.231:4500) <- 178.231.53.65:4500 MULTIPLE:MULTIPLE

    unfortunately, no connection, same time out.

    As additional info, I am using the stock Windows VPN client, PEAP with user certificate, but also tried with normal username and password using peap.</unauthenticated>



  • Ok, this thread can be closed. I have no idea how this happened, but I simply re-installed pfsense from scratch and suddenly outbound ikve2 worked properly. After adding the port forwards again, the VPN server behind the pfsense is also reachable using ikev2. Indeed using auto outbound nat.

    I have honestly no idea what setting in the GUI could have possible prevented the above from working, but at the very least it now works, I will add more portforwards and some other firewall rules + specific routing, and maybe I would be able to reproduce the problem and know what setting caused this, but to be honest, I just hope I never will :)

    Thanks for your patience.



  • Hmm I found out why this is occuring. MTU size !

    I did set the MTU to the WAN to 1500 but I need to set it to 1492 in order for this to work properly. I guess pfsense does not support RFC 4638 fully.

    This leads to another issue, as one of the routers of my ISP isn't sending ICMPv6 packet to big messsages back. So I manually adjust the RA to 1492. It seems that Pfsense takes the MTU of the lan adapter in /var/etc/radvd.conf.

    For now I just created a bash script that will kill radvd and relaunches it with a 1492 MTU size.

    Would there be a nicer way ?



  • @jvangent100:

    Would there be a nicer way ?

    Set [Interfaces: LAN] MTU 1492 too.


Log in to reply