Received N(TS_UNACCEPTABLE) message

rv@kaufmann.dkrv@kaufmann.dk
in Firebox - Networking, Multi-Wan, VLAN, NAT, SD-WAN

Setup is a central M370 cluster, now running 12.6.2 U3 and multiple T15 running 12.5.3 12.5.5 U1. Between each device is a bovpn vif tunnel using GRE.

For some time i have this problem a tunnel will not establish (for exampel if a T15 is power cycled) between the cluster and the end remote device. Yesterday i saw the issue again. It have not happened enough times for me to look futher into this or i have been to busy with other issues.

What was beeing logged on the T15 device was:
iked: msg_id="021A-0016" (T15<->M370)IKEv2 IKE_AUTH exchange from T15:500 to M370:500 failed. Tunnel='NetGroup'. Reason=Received N(TS_UNACCEPTABLE) message.

If i rekey the tunnel from the T15 device, the tunnel will not establish, only the second i rekey from the M370 cluster. This is consistent.

Today i search through Dimension for the logs, but can not find anything related to this issue (seems it´s not getting logged), so the only log i could find was the above from a support logfile i got from the T15 device with FSM. So i have no logs from the cluster side, but believe it was the same iked message.

This has happened through several fireware versions, and it only happens with tunnels configured as bovpn VIF. Before i moved all these tunnels to VIF interfaces, i never saw this issue. The same T15 devices also has a vpn tunnel to a second M370 cluster, but the tunnels a all configured without VIF and these tunnels never has this issue.

Any clue why fireware will report mismatching proxy ID´s and only a rekey from the cluster side will fix it and establish the tunnel?

Regards
Robert

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @RVilhelmsen
    With the log message, it would suggest that something in the proposal is not coming across from the T15 when it starts the proposal. We'd really need to dig into the logs when it's not working to get more data from that, though.

    If you have any ARRIS or Actiontec type ISP devices, I'd suggest checking the settings to ensure that there isn't an "ESP ALG" enabled on them. If there is, it can rewrite part of the VPN traffic (specifically the SPI headers) which can cause problems.

    -James Carson
    WatchGuard Customer Support

  • rv@kaufmann.dkrv@kaufmann.dk

    @James_Carson
    I am on the danish ISP TDC. All access ports provided form the ISP is completly open vlan ports, no ALG or proxies.

    The only way for me to get more logs is to enbale debug logging, but a have another case running where my Dimension server can´t handle all the logs, it receives, so currently i cannot enable more logning.
    But as i mentioned, it only happens on tunnels configured as VIF with GRE, not other types of tunnels.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @RVilhelmsen

    I'd suggest opening a case if you don't have one open for this already. It's difficult to really discern what the problem is within the confines of the forums.

    -James Carson
    WatchGuard Customer Support

  • rv@kaufmann.dkrv@kaufmann.dk

    @James_Carson
    I´ll do when i have the option to enable more logning. Have a good day.

  • FeldmeyerMFeldmeyerM

    Hello together

    I had this error (TS_UNACCEPTABLE) too , after a change from old BOVPN style to BOVPN-VIF + IKEv2
    The problem was the external IP, which was a private IP.
    The ISP router get only one external fixed IP and to internal a private range (192.168.178.0/24 ).
    Seems that the Firebox tries to establish a VPN tunnel with the external IP from that range
    There was a conflict with local IPs with a similar ISP connect.

    At the beginning, I did not assign virtual interface IP addresses under "VPN Routes".
    After doing so, the tunnel comes up stable.
    I used APIPA addresses (Out of 169.254.0.0/16) for it.

    regards Markus

  • PhilipPhilip

    I had this error (TS_UNACCEPTABLE) too , after a change from old BOVPN style to BOVPN-VIF + IKEv2
    The problem was the external IP, which was a private IP.
    The ISP router get only one external fixed IP and to internal a private range (192.168.178.0/24 ).
    Seems that the Firebox tries to establish a VPN tunnel with the external IP from that range
    There was a conflict with local IPs with a similar ISP connect.

    At the beginning, I did not assign virtual interface IP addresses under "VPN Routes".
    After doing so, the tunnel comes up stable.
    I used APIPA addresses (Out of 169.254.0.0/16) for it.

    Hello, I was having trouble doing the same thing. My external interfaces have IPs that I can't use. I have to use another public IP range to NAT traffic out. And I think that's why it wasn't working.
    I had another problem, my device was fully managed and my changes to the BOVPNs was not taking into account... it was pretty weird. But after putting it back to simply managed by the watchguard management server, I could recreate the BOVPN and it was working way better. With your post I managed to finalise a working configuration.

    Still have some snmp traffic problem trought that virtual BOVPN but that must be some specific things in my rules.

Sign In to comment.