Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 4 subscribers
  • Views 31521 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec VPN - no connection has been authorized with policy=PUBKEY -- after router exchange

utmliker

Hi all

I'm having an issue with IPsec side-to-side VPN tunnels since I had to exchange a vdsl router on one side.

The prior router had a IP forwarding function, the new one does only support port forwarding (DMZ function, where all ports are forwarded to a privat UTM IP as 192.168.1.1). So the change is, that the prior router passed the public IP to the UTM 9.5 and the new router does forward all ports to the private UTM IP 192.168.1.1. Use NAT traversal is activated.

BTW: On the other side there's a same router, which does also do NAT and worked flawless, till we exchanged the second router. Couldn't find any relevant differences between the two UTM configurations on both sides.

Check: If I'm initiating a portscan from the internet, the UTM does drop the packets, which means, the UTM is accessible from internet.

Issue

The side-to-side IPsec live log shows the following entries, if trying to initiate a connection by transferring payload:

2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: received Vendor ID payload [strongSwan]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: ignoring Vendor ID payload [Cisco-Unity]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: received Vendor ID payload [XAUTH]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: received Vendor ID payload [Dead Peer Detection]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: received Vendor ID payload [RFC 3947]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2017:10:03-19:18:51 utm-name pluto[7679]: packet from <utm-remote-ip>:1030: initial Main Mode message received on <utm-local-ip>:500 but no connection has been authorized with policy=PUBKEY

 

Any idea, why the tunnels do no more establish and how to solve the issue? What have I missed?



This thread was automatically locked due to age.
  • 0

    Before the router exchange the site to site VPN was working fine while on this UTM the WAN IP address was public. Now with the new router the setup is a site to site vpn where both UTMs are behind NAT (port forwarding enabled on both sites). Basically nothing was changed regarding the IPSEC configuration. For the VPN ID the hostname has been set statically to the name of the remote UTM.  According to some information in forums, this should propably be blank and probing of preshared keys should be activated. But not sure if this would help. Or would a solution with SSL-VPN instead of ipsec simplify the setup?

  • 0

    Hi and welcome to the UTM Community!

    By default, IPsec "signs" the first Main Mode message it sends with the IP of the interface.  The receiver checks that the signature is the same as the IP from which it receives the message.  If the only recent change was on your end, enter the public IP of your router into 'Preshared Key Settings' on the 'Advanced' tab and, as fanchy says, select probing.  Any luck with that?

    EDIT 2017-10-06: This post only applies if you're using a pre-shared key.  If you're using RSA keys, keep reading. [;)]

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob

    Thanks a lot for your reply. We tried do fix the issue based on your recommendation, but couldn't get it to work.

    IPsec > Advanced > Preshard Key Settings

    • VPN ID type was IP address. For VPN ID we entered as suggested the Public IP. Since it didn't, we also tried the private IP of the UTM WAN
    • Probing was enabled

    Since it didn't work, we changed IPsec > Remote Gateway  

    • VPN ID type: IP Address (prior type was Hostname)
    • VPN ID (optional): <empty> (our prior configuration contained the hostname of the remote site)

    IPsec > Local RSA Key VPN Options

    • in all tests we made sure, that the VPN ID settings matched between the Local RSA Key (local site) and Remote Gateway (remote site)

    Unfortunately, we couldn't get it to work. - Any idea, what we missed?

    Thanks for your appreciated support!

  • 0 in reply to utmliker

    Are you using a Preshared Key or are you using RSA keys?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    RSA keys. As read in another post, we also re-entered the keys, since this could also be an issue. As a trial, we also set up a SSL site-to-site VPN within minutes without any issue.

    But I would like to understand, how a IPsec site-to-site VPN with NAT on both sites works and we try not changing the implementation, because we couldn't get it work, as it should work. :-)

    Currently we restored the state without any test implementations. - So we have the state which worked before I had to exchange the router on my site which supports only NAT (port forwarding, with a DMZ function). Now we have the router and configuration, which works on the other VPN endpoint since many month.

    Is there a detailed step-by-step manual which explains IPsec site-to-site VPN behind NAT on both sites?

     

    PS: Our set up contains two separate tunnels, so that both sites have a remote network for NAS replication. Very cool solution, which is running for 10 years now, first with Juniper FW, since some years with Sophos UTM 9, which works more stable as the prior solution. - If it works.. ;-) lol 

  • 0 in reply to utmliker

    OK, RSA keys - ignore what I said about preshared keys (serves me right for not asking for pictures of the Edits of the IPsec Connection and Remote Gateway).  In that case, if you have followed The Zeroeth Rule in Rulz, use the Hostname option on the 'Local RSA Key' tab.  If that doesn't resolve this,

    1. Confirm that Debug is not enabled.
    2. Disable the IPsec Connection.
    3. Start the IPsec Live Log and wait for it to begin to populate.
    4. Enable the IPsec Connection.
    5. Show us about 60 lines from enabling through the error.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob

    I'm very sorry for the long delay.

    1. Yes, Debug mode is disabled.

    2. - 5. Here the first 60+ lines of IPsec Live Log:

     

    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [strongSwan]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [Cisco-Unity]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [XAUTH]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [Dead Peer Detection]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [RFC 3947]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2017:10:29-07:32:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: initial Main Mode message received on 192.168.x.101:500 but no connection has been authorized with policy=PUBKEY
    2017:10:29-07:32:42 <hostname> pluto[6355]: forgetting secrets
    2017:10:29-07:32:42 <hostname> pluto[6355]: loading secrets from "/etc/ipsec.secrets"
    2017:10:29-07:32:42 <hostname> pluto[6355]: loaded private key from 'Local X509 Cert.pem'
    2017:10:29-07:32:42 <hostname> pluto[6355]: listening for IKE messages
    2017:10:29-07:32:42 <hostname> pluto[6355]: forgetting secrets
    2017:10:29-07:32:42 <hostname> pluto[6355]: loading secrets from "/etc/ipsec.secrets"
    2017:10:29-07:32:42 <hostname> pluto[6355]: loaded private key from 'Local X509 Cert.pem'
    2017:10:29-07:32:42 <hostname> pluto[6355]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2017:10:29-07:32:42 <hostname> pluto[6355]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2017:10:29-07:32:42 <hostname> pluto[6355]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2017:10:29-07:32:42 <hostname> pluto[6355]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2017:10:29-07:32:42 <hostname> pluto[6355]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2017:10:29-07:32:42 <hostname> pluto[6355]: Changing to directory '/etc/ipsec.d/crls'
    2017:10:29-07:32:42 <hostname> pluto[6355]: added connection description "<vpnname>"
    2017:10:29-07:32:42 <hostname> pluto[6355]: "<vpnname>" #4: initiating Main Mode
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [strongSwan]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [Cisco-Unity]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [XAUTH]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [Dead Peer Detection]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [RFC 3947]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2017:10:29-07:32:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: initial Main Mode message received on 192.168.x.101:500 but no connection has been authorized with policy=PUBKEY
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [strongSwan]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [Cisco-Unity]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [XAUTH]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [Dead Peer Detection]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [RFC 3947]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2017:10:29-07:33:27 <hostname> pluto[6355]: packet from <unknown IP>:59540: initial Main Mode message received on 192.168.x.101:500 but no connection has been authorized with policy=PUBKEY
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [strongSwan]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [Cisco-Unity]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [XAUTH]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [Dead Peer Detection]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [RFC 3947]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2017:10:29-07:34:07 <hostname> pluto[6355]: packet from <unknown IP>:59540: initial Main Mode message received on 192.168.x.101:500 but no connection has been authorized with policy=PUBKEY
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [strongSwan]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [Cisco-Unity]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [XAUTH]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [Dead Peer Detection]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: received Vendor ID payload [RFC 3947]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    2017:10:29-07:34:47 <hostname> pluto[6355]: packet from <unknown IP>:59540: initial Main Mode message received on 192.168.x.101:500 but no connection has been authorized with policy=PUBKEY

    192.168.x.101 is the External (WAN) (Address) for the UTM gateway.

    Appreciating your support!

  • 0 in reply to utmliker

    It appears that the failure is right after the first Main Mode message, so that's either a disagreement about RSA keys or another misconfiguration.

    First, confirm that you have the other side's Public RSA Key and that they have yours.  You might want to send each other the keys to compare to what you already have.

    If that didn't fix the problem, it's time to see pictures of the Edits of the IPsec Connection, Remote Gateway and IPsec Policy.  Also, pictures of the corresponding configurations on the other side.  While you're at it, confirm that both sides have DPD enabled or both disabled.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob and all

    Well, as we had to realize, the internet access provider changed the configuration to CGNAT, which resulted in having different IP for sending and receiving. We could get CGNAT deactivated by the provider and the tunnel got running again.

    Some day later we had again issues with the VPN tunnels. So we decided to switch from IPsec to SSL Site-by-Site VPN. Since changing to SSL, we don't have any issues and the performance is even better than over IPsec.

    So, thanks for your appreciated support! - The issue is closed for us now.

Unfiltered HTML