how to route initiating client through alt gateway
Posted: Sun May 14, 2017 6:31 pm
I need to get the openvpn server to not use the default gateway while negotiating with the client. Heres why.
I had Ubuntu openvpn server going with openvpn clients on cell phones and tablets when out of the house roaming out in the wild so they could see inside the house. all fine.
I signed up for a paid VPN service for the outbound traffic. Put in a flashrouter with tomato and openvpn. Took out my original router. all fine.
Except that tomato can't do both openvpn client and openvpn server at the same time. (OBTW, this would be the right answer here.) It seems my VPN provider PIA doesn't offer inbound port forwarding on its US vpn servers. And the tomato doesn't monitor the local outside IP for inbound port forward requests. (I think this is odd, but can't figure out how or why simply putting a tomato port forward doesn't work with the outbound VPN client connected. It works with it is not connected.)
I set up my old router that worked in parallel with the new tomato router. (ok here's what in parallel means. Both are below the ISP modem/router. Both are connected to the inside lan. I don't have separate inside lans. the tomato is the default gateway. All inside PCs go out the tomato thru VPN. Only inbound VPN is to go through the old router.) I can get inbound vpn client requests to be forwarded through the old router to the Ubuntu openvpn server, but the server doesn't know to route back through the old router for those early client negotiation packets. (This is while the initiating client is using its outside IP before the tunnel is up.) The openvpn server routes replies back through the default gateway so the packets get lost out the VPN. At least that what I think is going wrong. (The openvpn server logs sees the initial client request. it hears client ping and replies with a ping, but that cycle repeats until a timeout ."TLS key negotiation failed to occur within 60 seconds (check your network connectivity)")
I know its both unusual (all the support desks disavow me and googling this set up gets no hits) and complex (makes my head hurt trying to follow the packets in and back out) but I think this will work.
Seems like I need a special purpose routing rule on the Ubuntu (openvpn) server or in the openvpn config itself that says clients that are out in the wild trying to connect aren't to be reached behind the default gateway but behind the alternate gateway. is there an openvpn server config stanza that says all clients are behind the alt gateway and not the default gateway?
I don't want to just tell the hosting Ubuntu that its default gateway is the alt router because it does several other otherwise-normal things like be the entertainment center box that want to go out the new VPN service.
Ideas? Got questions for clarification of the setup? I know its unusual and hard to describe.
Thanks in advance. Clark
I had Ubuntu openvpn server going with openvpn clients on cell phones and tablets when out of the house roaming out in the wild so they could see inside the house. all fine.
I signed up for a paid VPN service for the outbound traffic. Put in a flashrouter with tomato and openvpn. Took out my original router. all fine.
Except that tomato can't do both openvpn client and openvpn server at the same time. (OBTW, this would be the right answer here.) It seems my VPN provider PIA doesn't offer inbound port forwarding on its US vpn servers. And the tomato doesn't monitor the local outside IP for inbound port forward requests. (I think this is odd, but can't figure out how or why simply putting a tomato port forward doesn't work with the outbound VPN client connected. It works with it is not connected.)
I set up my old router that worked in parallel with the new tomato router. (ok here's what in parallel means. Both are below the ISP modem/router. Both are connected to the inside lan. I don't have separate inside lans. the tomato is the default gateway. All inside PCs go out the tomato thru VPN. Only inbound VPN is to go through the old router.) I can get inbound vpn client requests to be forwarded through the old router to the Ubuntu openvpn server, but the server doesn't know to route back through the old router for those early client negotiation packets. (This is while the initiating client is using its outside IP before the tunnel is up.) The openvpn server routes replies back through the default gateway so the packets get lost out the VPN. At least that what I think is going wrong. (The openvpn server logs sees the initial client request. it hears client ping and replies with a ping, but that cycle repeats until a timeout ."TLS key negotiation failed to occur within 60 seconds (check your network connectivity)")
I know its both unusual (all the support desks disavow me and googling this set up gets no hits) and complex (makes my head hurt trying to follow the packets in and back out) but I think this will work.
Seems like I need a special purpose routing rule on the Ubuntu (openvpn) server or in the openvpn config itself that says clients that are out in the wild trying to connect aren't to be reached behind the default gateway but behind the alternate gateway. is there an openvpn server config stanza that says all clients are behind the alt gateway and not the default gateway?
I don't want to just tell the hosting Ubuntu that its default gateway is the alt router because it does several other otherwise-normal things like be the entertainment center box that want to go out the new VPN service.
Ideas? Got questions for clarification of the setup? I know its unusual and hard to describe.
Thanks in advance. Clark