Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 1 subscriber
  • Views 1405 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 routing issue

BorisTheSpider
I have a little routing issue using SSL VPN.

When I connect, I can look in the openVPN client log and see that a route is being pushed with a netmast of /32 so that the route to my LAN interface (which answers to webadmin connections) is being defined via the pre-existing default gw (the astaros address on the separate wireless LAN from which I am connecting). The result is that the packets are attempting to hit the astaro via the wireless lan interface rather than through the vpn so I can't access webadmin when I'm VPN'd in this way. If I do a route delete , then the default route via the vpn is left and it works again. I'd have to do this every time I connected though, as openvpn sucks the route from the peer on connection. How do I fix this so the astaro stops pushing this particular route? I can't actually even see why that route is needed anyway, but perhaps I'm missing something. Certainly nothing breaks when it's not there after manually deleting it, so I wonder why it's there at all.


This thread was automatically locked due to age.
Parents
  • 0
    OK, a little more thought and I answered my own question, so I'll post the answer now for the benefit of anyone else who's tried the same thing.

    The route I referred to - a /32 bit masked route to the address OpenVPN is connecting to via your (actual, non-vpn) default gw is there so openvpn can get to the endpoint!

    Hence, if the openvpn endpoint is also the address you will try to connect to webadmin on, and it doesn't listen for webadmin connections, it won't work.

    What I did in the end was add an additional address to the interface on which the openvpn listens for connections from the LANs, then that address became localvpn.mydomain.com which is then configured in the .ovpn file on the client. That way I can let that address have a host route via the actual (wireless lan) default gw, but the traffic to the other address on that same interface, where webadmin listens, goes via the VPN tunnel as desired.
Reply
  • 0
    OK, a little more thought and I answered my own question, so I'll post the answer now for the benefit of anyone else who's tried the same thing.

    The route I referred to - a /32 bit masked route to the address OpenVPN is connecting to via your (actual, non-vpn) default gw is there so openvpn can get to the endpoint!

    Hence, if the openvpn endpoint is also the address you will try to connect to webadmin on, and it doesn't listen for webadmin connections, it won't work.

    What I did in the end was add an additional address to the interface on which the openvpn listens for connections from the LANs, then that address became localvpn.mydomain.com which is then configured in the .ovpn file on the client. That way I can let that address have a host route via the actual (wireless lan) default gw, but the traffic to the other address on that same interface, where webadmin listens, goes via the VPN tunnel as desired.
Children
No Data