IKEv2 Connection Not Working to RRAS

Options
NEP
NEP Posts: 116 image  Ally Member
First Comment Friend Collector Third Anniversary
edited February 22 in Security

Hello,

I'm trying to set up an RRAS (Routing and Remote Access Services) VPN on Windows Server. This is a built-in Microsoft role that can be installed. Being new to this, I'm not sure if I have everything set up correctly. It seems like it is, but I cannot get the VPN connection to actually work.

First the RRAS server was created and configured to accept EAP-MSCHAPv2 encryption. This appears to be the standard for iOS and Android. Then that was linked to NPS (Network Policy Server) for authentication to AD. I confirmed that NPS auth is working with NTRadPing. Then in the ATP800, I created a 1:1 NAT which passes traffic on UDP 500/4500 from a separate Public IP to the RRAS server. There is also SNAT set up to make that traffic return to the external device on the same IP.

After that an IKEv2 VPN connection was created on an iOS device. Tapping the Connect toggle results in the toggle almost immediately turning off. I checked in the ATP logs and it sees the connection coming in and logs that it was directed through NAT to RRAS. I tried all kinds of stuff, including making sure that NAT-T (AssumeUDPEncapsulationContextOnSendRule) was set to 2 on the RRAS server. Nothing seems to work. Finally, I installed Wireshark and saw that traffic is indeed arriving at RRAS and there appears to be a dialog between it and the device before it disconnects (ie. stops responding).

In talking with AI (maybe my first mistake), it sounds like the ATP800 might be messing up the connection because we already have IPSec connections set up. The issue seems related to swapping from UDP 500 to 4500 in the connection process. AI says that, "Zyxel ATP devices do not reliably support IKEv2 passthrough when the firewall itself is also running IPSec VPNs." I would hope this isn't the case, but I really don't have any other clue as to what is wrong.

Two other things to note, I tried an Android device as well and it fails the same way. All of the tutorials that I have looked at show the RRAS server being on a Public IP. I don't like the sounds of that and found posts that it should work to place it behind the firewall. AI tended to agree (second mistake?).

Anyway, if anyone has any pointers I would greatly appreciate it. Been working on this for what seems like too long and kind of losing my mind. The reason behind setting this up is related to insurance and MFA. We opted for RRAS because we don't like how the Zyxel SSL VPN (deprecated) works with MFA and research seems to indicate that IPSec does not work nicely with MFA. Maybe that isn't the case though.

Thank you for your time!

Edit: Added and changed some text for clarity.

«13

All Replies

  • PeterUK
    PeterUK Posts: 4,426 image  Guru Member
    250 Answers 2500 Comments Friend Collector Eighth Anniversary

    From what I know I don't think you need the (AssumeUDPEncapsulationContextOnSendRule) any more it should work without.

    So from what I understand on the ATP800 you have setup a Remote Access (Server Role)?

    Try disabling other VPN connections to rule out problem.

    Also MS default if its still the case for:

    Phase 1
    Encryption 3DES
    Authentication SH1
    Key Group DH2
    Phase 2
    Encryption AES128
    Authentication SH1
    Perfect Forward Secrecy none

  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary
    edited February 22

    Neither of the state main values (ie. 0 and 2) for AssumeUDP worked, so your thought is probably correct.

    Not sure I understand your ATP800 statement, but yes RRAS is a Windows Server role.

    Thanks for the nudge, but I don't want to disable the other VPN connections, as they connect to other offices.

    The MS default info that you gave appears to be for an IPSec VPN tunnel. That is similar to our other VPNs. However, the standard for iOS and Android appears to be EAP-MSCHAPv2, so that is what I used.

    Thank you for the info PeterUK. Hopefully one of the Zyxel techs can get involved and clarify whether IKEv2 Passthrough is possible and/or if this could remotely be the issue.

  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary

    I went looking in the manual and then found that "Remote Access (Server Role)" (what you mentioned) is a VPN option under IPSec VPN in the ATP800. I understand what you meant now, but no I did not configure that at all. I just set this up like I would any other port forward with NAT, SNAT (Routing), and Policy Control. I didn't realize that it mattered. I figured traffic would come through and be processed like any other port traffic. Seems like VPN traffic must trump other traffic. Is this the case?

  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary

    This morning it dawned on me that maybe Policy Control for RRAS was below the other VPNs and therefore being redirected out on them. Unfortunately, that does not appear to be the case.

  • Zyxel_Melen
    Zyxel_Melen Posts: 4,616 image  Zyxel Employee
    Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Switch Zyxel Certified Network Administrator - Nebula Zyxel Certified Sales Associate

    Hi @NEP

    Please allow me to clarify the scenario first.

    The current issue is that the clients under ATP can't connect the RRAS during ATP having other site-to-site VPN? And the client's outgoing interface is the interface that you create the NAT rules (which is a separate Public IP to the RRAS server)?

    Zyxel Melen


  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary
    edited February 24

    @Zyxel_Melen Thank you for responding. I don't really know how to answer that because I don't know what the actual issue is. Copilot seems to think that the ATP could be interfering with those connections due to having other active site-to-site VPNs that utilize 500/4500. I don't know, which is why I posed the question. The only thing I know for sure is that the RRAS VPN does not work for external clients.

    1. An external client (eg. iOS phone) initiates a connection by toggling the VPN on.
    2. That points to an external DNS name which points to a separate IP (in a block) of our ATP800.
    3. The ATP receives the connection and passes it on to the RRAS server via NAT and Policy Control.
    4. The connection then shows up in Wireshark on the RRAS server.
    5. Routing/SNAT was configured for the return traffic.
    6. It goes back and forth a couple of times (output in orig post), changes from 500 to 4500 (see below), and then drops.

    Can you confirm that with the following Policy Control all traffic should come in and be redirected to the RRAS server?

    • From: WAN
    • To: LAN
    • IPv4 Source: USA
    • IPv4 Destination: RRAS server IP
    • Service: 500/4500
    • Action: Allow

    Also, that setting up the following Routing/SNAT should direct that traffic back to the external client?

    • Incoming: Any
    • Source: RRAS server IP
    • Destination: Any
    • Service: 500/4500
    • Next-Hop: Any
    • SNAT: Public IP of RRAS

    I'm mainly looking to make sure that no internal routing of the ATP would prevent this type of connection. If it doesn't, do you have any idea what could be? It seems to be related to the ATP and NAT-T, but I don't know much about how either of these work.

    Thank you for your time.

  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary
    edited February 24

    Oddly enough, this morning while attempting to connect I saw an "Audit Success" entry in Event Viewer. The body of that says "Network Policy Server granted access to a user" and lists out the IP of the test phone it was run from. That is the first time that has happened. Without any changes from before. And it hasn't happened since. Again without any changes. Not sure what to think about that.

    Copilot mentioned IKEv2 fragmentation and this made a coworker think MTU issue. So we changed the MTU size on the RRAS server to 1350, but it did not improve the situation. Nor did 1300. I had read in another Community thread that IKEv2 fragmentation was not supported. Not sure if that is the case for the ATP800.

  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary
    edited February 24

    I did a packet capture from the ATP and after the other Wireshark output is…

    6 2.040353 (RRAS Public IP) (Phone IP) IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=f9bc)

    Not sure if that is related.

  • mMontana
    mMontana Posts: 1,468 image  Guru Member
    Zyxel Certified Network Administrator - Security Zyxel Certified Network Administrator - Switch 50 Answers 1000 Comments

    My few cents for the knowledge I have.

    "AssumeUDPEncapsulationContextOnSendRule" value must be 2.
    The VPN Endpoint is behind a NAT, and probably will be the end-user with cellular, home or hospitality connection.

    The routing SNAT rule should not have Next-Hop: Any but the connection which is wired for the 1:1 NAT.

    You can try to diagnose if it's your windows setup or the ATP800 configuration adding a know-working VPN Server (could be any appliance or a linux distro) in the same subnet of your windows server, then change the ATP800 config using this spare equipment address rather than the windows server.

    Then try… If your spare device works, probably something must be tuned in Windows, otherwise is still making the things work on ATP800.

    Last but not least: there's an image on ZLD 5.x for diagnostic the flow of packets. You know that currently incoming packages are forwarded to windows, now it's time to trace back the outgoing from the server to WAN.

  • NEP
    NEP Posts: 116 image  Ally Member
    First Comment Friend Collector Third Anniversary
    edited February 25

    Thanks @mMontana. I verified that AssumeUDP… is set to 2. I also changed the Next-Hop to the Interface that the Public IP of the RRAS server comes in on. The situation is the same. As for trying a known-working VPN, we don't have anything outside of Zyxel's SSL and IPSec VPN solutions. Do you have any recommendations for something that can be set up easily/temporarily? I looked around a little bit and found SoftEther VPN and strongSwan. Do you have any experience with either? I didn't understand your "image on ZLD 5.x for diagnosing the flow of packets". What did you mean by that? That said, I did use Packet Capture on the ATP (partial screenshot below) and it shows the Destination being the RRAS Public IP. It seems like the packets are being sent where they are supposed to but I don't really know. Is there something else I should check?

    To rule out NPS being an issue with regard to authentication, I removed it from the server and now that takes place in RRAS. Still the same. In Wireshark the filter was changed to ip.host matches "174.216" from udp.port==500 or udp.port==4500 to allow seeing more logging. The following is the output that is seen. It seems more and more like fragmentation might be the issue. @Zyxel_Melen Do you guys have any further input?

    image.png

    Thanks everyone!

Categories

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）