Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 5770 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

SSL VPN has no route back

gravyface
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.
Parents
  • 0
    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).
  • 0 in reply to gravyface
    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.
  • 0 in reply to TheDrew
    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.
  • 0 in reply to gravyface
    Patched from 7.502 to 7.504, rebooted, all good.
Reply Children
No Data