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 has no route back

Have the SSL VPN up and "working" with certs: can authenticate no problem, but can't connect/ping etc. anything on the Internal Network.  

I've added the local subnet ("Internal Network") and I've unchecked the "automatic packet filtering rules" and added my own rules (allow SSL VPN pool -> RDP -> Terminal Servers).  I can see the packets getting through in the live log, but nothing is coming back to the client (Ubuntu running OpenVPN in daemon mode with a client configuration).  Routes are fine on Ubuntu (like I said packets are getting through according to the Live Log).

Do I need to add static routes?  Seems odd to have to do that.


This thread was automatically locked due to age.
  • Here's what I'm seeing in the OpenVPN log; not sure why it can't add that route:

    2010:04:05-21:39:15 gravyedge openvpn[14166]: /bin/ip addr add dev tun1 local 10.242.2.1 peer 10.242.2.2
    2010:04:05-21:39:15 gravyedge openvpn[14166]: /usr/bin/openvpn_updown.plx up tun1 1500 1556 10.242.2.1 10.242.2.2 init
    2010:04:05-21:39:16 gravyedge openvpn[14166]: /bin/ip route add 10.242.2.0/24 via 10.242.2.2
    2010:04:05-21:39:16 gravyedge openvpn[14166]: ERROR: Linux route add command failed: external program exited with error status: 2
  • Your first post made me think you might need to fix the default gateway on the target behind the Astaro.  Also wondered if you have everything you need checked on the 'ICMP' tab of 'Packet Filter' so pings are allowed.

    Your second post seems like it comes from the Ubuntu machine... what's going on in the Astaro at the time?

    Cheers - Bob
  • Nope, that logs from the Live Log output for the SSL VPN (with debugging enabled).

    Let me see what's up with the packet filtering under ping, but even trying to telnet to the Terminal Server on 3389 isn't working either -- the packets get there, I can see the green accept lines scroll by in the packet filtering live log, it's just acting like there's no route back to the tun interface (10.242.2.5 my gw, .6 is my tun IP on the client side).
  • Is the IP of the Astaro's "Internal (Address)" the default gateway for the device you're trying to ping in your internal network?
  • Is the IP of the Astaro's "Internal (Address)" the default gateway for the device you're trying to ping in your internal network?


    Yes, all the hosts on that network (10.1.1.1/24) have the Astaro as the default gateway.
  • What happens if you ping from WebAdmin 'Support >> Tools'?  What happens if you check auto packet filter rules?
  • What do you want me to ping?
  • Let me see what's up with the packet filtering under ping, but even trying to telnet to the Terminal Server on 3389 isn't working either -- the packets get there, I can see the green accept lines scroll by in the packet filtering live log, it's just acting like there's no route back to the tun interface (10.242.2.5 my gw, .6 is my tun IP on the client side).


    I've run into a similar situation with our VPN config. In our case the Astaro isn't the default gateway for the network and there are no routing rules in place to handle the path back to the VPN client IP ranges.

    My solution in the end was to setup NAT on the IP ranges used by our VPN clients so the traffic appears to come from the Astaro, which is routable as it's on the same LAN.
  • I've run into a similar situation with our VPN config. In our case the Astaro isn't the default gateway for the network and there are no routing rules in place to handle the path back to the VPN client IP ranges.

    My solution in the end was to setup NAT on the IP ranges used by our VPN clients so the traffic appears to come from the Astaro, which is routable as it's on the same LAN.


    I've done asynchronous tunneling before with routes, but in this case, I don't want to NAT the VPN clients onto the LAN because I have different rules that apply to the VPN pool subnet (it's a very restrictive VPN setup for this particular group; they do split tunneling, but I'm only permitting 3389 to the Terminal Server).  Right now it's wide open for them, but I'm still not getting any packets back.  Doing updates tonight and rebooting so we'll see how that goes.
  • Patched from 7.502 to 7.504, rebooted, all good.