Guest User!

You are not Sophos Staff.

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

SSL VPN not working after upgrade to 9.309-3

Hi,

I manage 2 UTM 9 connected one another with site-to-site SSL vpn. Apart from this, both are also reachable through SSL VPN client.

I updated this weekend one of them from to v 9.309-3 and left the other one still at v 9.308-16. Result is that site-to-site between the two still works fine but if i try to do ssl vpn from any computer through vpn client to the one with v 9.309-3, i can get connected (light turns green) but cannot reach and/or ping any of the devices behind its internal network. SSL vpn on the other one v 9.308-16 still works without any issue.

Keeping in mind that:
-I didn't change anything in the configuration...i merely performed the update
-If i log the traffic going to the vpn, i see that the pings (or eg rdp requests) are marked green and the destination addresses are correct
-I compared the configuration side-by-side of the working one with the other and i don't see any difference...dns and so remained the same on both sides
-I reissued the configuration file for the existing user I was trying and even created a new user on a nother computer, tryed to connect but...no joy

I repeat, The client connects and the requests and packets actually reach the utm (I can see that through the green logs) but I cannot do anything...no rdp, no shared folders, negative pings.

I searched around but didn't find any useful article so fare and is quite surprising that i am the only one having this issue.

Can anyone please shed some light on this or suggest what possible other steps i can take other then restoring a conifg previous to the upgrade.

Of coure also all the packet filterings rules had been turned off during the tests (and i didn't expect to have any benefit, since they have been always on even before the upgrade).

Braking my head on this. Need some advice.

Thanks

Ed


This thread was automatically locked due to age.
  • [:@]

    The exact same thing here for IPSEC and / or L2TP but ramdomized:

    Somtimes it works, some minutes later not. Wether client- or UTM-Logs are helpful at the moment.

    Especially MAC-OSX-Clients do have heavy difficulties since I upgraded to 9.309-3. 

    (The VPN-Settings are the same since 1,5 years or so, just updated the Software UTM (active/passive cluster) to 9.309-3.
  • What happen right after the packet arrives? If i see the attached image I would say it gets forwarded to the right destiantion (in this example i was trying to esatblish an rdp session). Where else can I go and inspect further?
      ">
  • It turns out to be not really a version problem, since another UTM with the latest update is working. 
    I narrow down the problem to be a vpn ip conflict, meaning that my remote ssl session gets the same IP number as the site-to-site session (10.240.0.6). So if i turn off the site-to-site i can ping my machines through the remote, the moment i turn the site-to-site back on then i lose the pings.

    Is there not supposed to be a dhcp service for the vpn to avoid this kind of conlficts? I tried to give a fixed ip to the remote user via the user management, but it doesn't seem to work? Any suggestion? Or do i have to start a new thread?
  • tekpoint:

    Go --> Definitions and Users --> Network Definitions

    Find "VPN Pool (SSL)" --> Press EDIT

    Change the IP network to something that do not conflict with your setup, reconnect the SSl VPN client (Diconnect / connect) and you will get the new range...

    How does that go?

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • Else make a whole NEW Pool for the SSL VPN CLIENTS only here:

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • Thanks Twister5800,

    Thank you! Your post crossed my actions...i did what you are suggesting before i saw your answer and it seems to be working now. However, question remains...will this be happening again? 
    Before I had as IP 10.242.2.6, now i changed subnet and guess what IP i am getting? 10.242.3.6  It always points to the "6" which if i am not mistaken is shared also with the site-to-site. An ip scan on the range brings as only hosts alive 10.242.3.1 (the gateway i guess) and 10.242.3.6 (my pc). Are site to site and regular vpn sharing one address?
  • Yes site-to-site SSL and SSL VPN Clients, shares the same IP range, that's why the text:

    Virtual IP addresses for peers are selected from this IP pool. It may be changed or replaced to resolve conflicts. For SSL site-to-site connections it is possible to assign a peer a static virtual IP address, which bypasses use of this pool


    Is there :-)

    Why do you not use IPSEC for site-to-site, it's way faster?

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • Didn't think about using ipsec for site-to-site. Will check that out in a moment
  • Yes site-to-site SSL and SSL VPN Clients, shares the same IP range, that's why the text:



    Is there :-)

    Why do you not use IPSEC for site-to-site, it's way faster?


    Twister5800,

    Settled for IPSEC for the site-to-site and ssl for regular client vpn [:)]

    Thanks for the help
  • I did resolve this for me, too and it was also a kind of "duplicate IP".

    Just for the records:

    In my case it is HA-related.

    Reason: 
    I noticed that it was always the first IP from the IPSEC-IP-Pool which could not route any traffic through the tunnel.
    First I thought that there is some device in the DMZ using this IP but could not find any.
    So I changed the IP Pool to a different one and now it was working as expected.
    During further investigation I came to over entry in ipsec.log:

    ""D_REF_IpsRoaMwxtest2_0"[190] 79.228.236.174:4500 #1502: ERROR: netlink XFRM_MSG_NEWPOLICY response for flow tun.0@79.228.236.174 included errno 17: File exists""


    Google pointed me to  this old topic and that makes sense.

    hth - Chris