New Member
Posts: 11
Registered: ‎09-26-2014
Solutions: 1
Accepted Solution

One way VPN - out at sea!

Hi All,

 

I have a requirement to setup access to a network on a barge for the purpouse of monotoring and configuring equipment on board. The issue I have is that we cannot open ports on the mobile internet router on the barge. 

 

I think what I need is a VPN configuration I can setup on a edgerouter that will connect to our office router and allow bi-directional traffic. Im just not sure what VPN type to use and what other configuration would be required. Office has a static IP and an edgerouter. 

 

I have setup site-to-site networks before that required a VPN from each end, and the edgerouter was the gateway on each end of the network. This situation is very different where our hardware (an edgerouter) will be another device on the same LAN as the equipment sitting behind the router / firewall and our VPN will need to traverse through this network. 

 

Any pointers / advise would be most appreciated. 

 

Thanks 

 


Accepted Solutions
New Member
Posts: 11
Registered: ‎09-26-2014
Solutions: 1

Re: One way VPN - out at sea!

Thanks everyone for the help so far.

 

Just setting up some config files for the routers and im wondering what I would enter for the "remote-host" preameter on the land based (known IP address end) router as I dont know what the salty router's IP will be, pluss its behind the firewall. 

 

So far I have the below, based on a config I have used for an office to office VPN

 

Land Based router

 

set interfaces openvpn vtun10

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 local-address 10.11.1.99

set interfaces openvpn vtun10 remote-address 10.12.2.99

set interfaces openvpn vtun10 local-port 9621

set interfaces openvpn vtun10 remote-port 9621

set interfaces openvpn vtun10 remote-host "XXXXX - Unknown"

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/key.secret

set interfaces openvpn vtun10 openvpn-option "--comp-lzo"

set interfaces openvpn vtun10 openvpn-option "--float"

set interfaces openvpn vtun10 openvpn-option "--ping 10"

set interfaces openvpn vtun10 openvpn-option "--ping-restart 20"

set interfaces openvpn vtun10 openvpn-option "--ping-timer-rem"

set interfaces openvpn vtun10 openvpn-option "--persist-tun"

set interfaces openvpn vtun10 openvpn-option "--persist-key"

set interfaces openvpn vtun10 openvpn-option "--user nobody"

set interfaces openvpn vtun10 openvpn-option "--group nogroup”

 

 

Salty Sea based router

 

set interfaces openvpn vtun10

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 local-address 10.12.2.99

set interfaces openvpn vtun10 remote-address 10.11.1.99

set interfaces openvpn vtun10 local-port 9621

set interfaces openvpn vtun10 remote-port 9621

set interfaces openvpn vtun10 remote-host LandBasedRouterIP

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/key.secret

set interfaces openvpn vtun10 openvpn-option "--comp-lzo"

set interfaces openvpn vtun10 openvpn-option "--float"

set interfaces openvpn vtun10 openvpn-option "--ping 10"

set interfaces openvpn vtun10 openvpn-option "--ping-restart 20"

set interfaces openvpn vtun10 openvpn-option "--ping-timer-rem"

set interfaces openvpn vtun10 openvpn-option "--persist-tun"

set interfaces openvpn vtun10 openvpn-option "--persist-key"

set interfaces openvpn vtun10 openvpn-option "--user nobody"

set interfaces openvpn vtun10 openvpn-option "--group nogroup”

 

Any thaughts? The land based router wont be able to contact the sea based router as ports will be firewalled and IP unknown, but im hoping the link will be establised first by the sea based router.

 

Will this even work?

 

Thanks again for your help and time. This community is such an asset to the UBNT product line. 

 

MikeC

View solution in original post

Highlighted
Member
Posts: 129
Registered: ‎03-15-2014
Kudos: 34
Solutions: 10

Re: One way VPN - out at sea!

[ Edited ]

I've actually got something similar to this in production. It's openvpn as well. Minus the water. And the addresses reversed... My setup has the client on a static IP, and my (small)NOC on a dynamic IP, linked to a domain name. Yeah... it's odd, but it's been bulletproof for a couple years. I've got the traffic firewalled and NATed so my NOC can reach out and query all of the equipment on their side, but the traffic originating from my client's side will be dropped at the NOC NAT address.

As mine is set, the client always initiates the connection. The client is behind a NATed firewall, and the agency is absolutely NOT going to open a firewall port for inbound connections from my NOC to the VPN. So... the client has to initiate the connection to my NOC. Since my NOC WAN is dynamic, I had to tie it to a DynDNS hostname, which the client could then resolve to initiate a connection in the event my NOC WAN changed (does all the time...). Since hostname is static, but DNS resolution is dynamic, I don't have to change the client's router to re-establish a connection. I also allowed their security folks to be happy with the firewall remaining in place. Finally, my small NOC has the advantage of being able to float around address-wise and not have a single WAN address to be targeted by the a**holes out there.

As for routes, my NOC is aware of the address segment assigned to the equipment I'm monitoring on the Client's network. Simple static next hop route. Destination 192.168.XX.0/24, next hop 10.1.1.2. NAT rule translates traffic to the client to the 10.1.1.1 address, so all my client's network sees is my 10.1.1.1 vtun address querying equipment, and the equipment responds to that NAT address. Sneaky, but it works perfectly. The client's side only has the route to the NAT addresses that was automatically created with the VTUN. So... the client's routing table only shows destination 10.1.1.1&2/32 going to the interface vtunXX.

 

So comparing to my setup, I see the following:
I don't have the --user and --group tags even specified. Never needed them.
Next important thing is to leave the remote-host BLANK on the Land Lubber router. This is especially important if your Salty Sea router has a dynamic WAN IP address, or has any potential to change. If it has something in it, it may try to resolve and upon failure, it may deny the VPN.
Finally, I don't see any subnet mask specified for the local-address. Might be a good idea, since this is just the tunnel address.


Hope this makes sense. Typed up after a LONG day doing too much mountain work, so if it's fuzzy, that's how my brain is this evening.

View solution in original post


All Replies
SuperUser
Posts: 20,402
Registered: ‎09-17-2013
Kudos: 5144
Solutions: 1458

Re: One way VPN - out at sea!

if you can do everything via commandline, a reverse ssh tunnel should be doable.

 

Otherwise, if you set the (ship) ER as the VPN Client, you could have it semi-permanently connect to your server on-shore, and then just access it through the VPN -- you'll just need to add routing in your office's router to direct computers to the VPN server when trying to access that shipboard ER ...

New Member
Posts: 11
Registered: ‎09-26-2014
Solutions: 1

Re: One way VPN - out at sea!

Thanks 

 

 

 

SuperUser
Posts: 20,402
Registered: ‎09-17-2013
Kudos: 5144
Solutions: 1458

Re: One way VPN - out at sea!

[ Edited ]

@nzmikec wrote:

Thanks 

 

 

 


 

Edit to hopefully make this clearer ...

 

1. Create the tunnel from the ship to the mainland, this can be done from the ER, or some other host on the ship:

 

ssh -R 5000:localhost:22 landlubber@mainland-server

 

2. From any other PC  in the office (i.e. on land), connect to "mainland-server"

 

ssh user@mainland-server

 

3. Connect "backwards" through the previously opened tunnel

ssh -p 5000 seadog@localhost

^ note that you have to use a valid user for the SHIP host (in this case "seadog"), and not necessarily "landlubber" or your username that you logged into mainland-server with.

 

If the guys on the ship are somewhat technically competent, you can just walk them through resetting the SSH connection if it's lost.  If they're not, there are tools that'll automate the reconnection.

 

In addition, instead of keeping a terminal window always up, you can nohup the initial tunnel creation (nohup ssh -R [...]), so it'll survive user logout / session termination (won't survive a reboot ... or systemd determining that no really you didn't want that to keep running). 

 

Finally, there are other switches for ssh to stop the reverse tunnel from creating an interactive session on mainland-server (-f to background after initiating the connection, and -N to stop the session from executing any remote commands / login scripts).  These aren't "necessary" for things to work, but they may make it easier to manage long term (reduce log sizes, etc.).

Veteran Member
Posts: 8,112
Registered: ‎03-24-2016
Kudos: 2133
Solutions: 933

Re: One way VPN - out at sea!

why the ssh hassle ?

 

I'd go for either

- ipsec, using ddns and certificates

or

-openvpn

New Member
Posts: 11
Registered: ‎09-26-2014
Solutions: 1

Re: One way VPN - out at sea!

Thanks, 

 

I have an extra ERX comming and will test a openvpn network. Would you suggest a site-to-site config at each end? or is there a better suited network type? 

 

Cheers,

 

MikeC

Veteran Member
Posts: 8,112
Registered: ‎03-24-2016
Kudos: 2133
Solutions: 933

Re: One way VPN - out at sea!

bi-directional traffic.....translates over here into site2site

New Member
Posts: 11
Registered: ‎09-26-2014
Solutions: 1

Re: One way VPN - out at sea!

Thanks everyone for the help so far.

 

Just setting up some config files for the routers and im wondering what I would enter for the "remote-host" preameter on the land based (known IP address end) router as I dont know what the salty router's IP will be, pluss its behind the firewall. 

 

So far I have the below, based on a config I have used for an office to office VPN

 

Land Based router

 

set interfaces openvpn vtun10

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 local-address 10.11.1.99

set interfaces openvpn vtun10 remote-address 10.12.2.99

set interfaces openvpn vtun10 local-port 9621

set interfaces openvpn vtun10 remote-port 9621

set interfaces openvpn vtun10 remote-host "XXXXX - Unknown"

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/key.secret

set interfaces openvpn vtun10 openvpn-option "--comp-lzo"

set interfaces openvpn vtun10 openvpn-option "--float"

set interfaces openvpn vtun10 openvpn-option "--ping 10"

set interfaces openvpn vtun10 openvpn-option "--ping-restart 20"

set interfaces openvpn vtun10 openvpn-option "--ping-timer-rem"

set interfaces openvpn vtun10 openvpn-option "--persist-tun"

set interfaces openvpn vtun10 openvpn-option "--persist-key"

set interfaces openvpn vtun10 openvpn-option "--user nobody"

set interfaces openvpn vtun10 openvpn-option "--group nogroup”

 

 

Salty Sea based router

 

set interfaces openvpn vtun10

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 local-address 10.12.2.99

set interfaces openvpn vtun10 remote-address 10.11.1.99

set interfaces openvpn vtun10 local-port 9621

set interfaces openvpn vtun10 remote-port 9621

set interfaces openvpn vtun10 remote-host LandBasedRouterIP

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/key.secret

set interfaces openvpn vtun10 openvpn-option "--comp-lzo"

set interfaces openvpn vtun10 openvpn-option "--float"

set interfaces openvpn vtun10 openvpn-option "--ping 10"

set interfaces openvpn vtun10 openvpn-option "--ping-restart 20"

set interfaces openvpn vtun10 openvpn-option "--ping-timer-rem"

set interfaces openvpn vtun10 openvpn-option "--persist-tun"

set interfaces openvpn vtun10 openvpn-option "--persist-key"

set interfaces openvpn vtun10 openvpn-option "--user nobody"

set interfaces openvpn vtun10 openvpn-option "--group nogroup”

 

Any thaughts? The land based router wont be able to contact the sea based router as ports will be firewalled and IP unknown, but im hoping the link will be establised first by the sea based router.

 

Will this even work?

 

Thanks again for your help and time. This community is such an asset to the UBNT product line. 

 

MikeC

Highlighted
Member
Posts: 129
Registered: ‎03-15-2014
Kudos: 34
Solutions: 10

Re: One way VPN - out at sea!

[ Edited ]

I've actually got something similar to this in production. It's openvpn as well. Minus the water. And the addresses reversed... My setup has the client on a static IP, and my (small)NOC on a dynamic IP, linked to a domain name. Yeah... it's odd, but it's been bulletproof for a couple years. I've got the traffic firewalled and NATed so my NOC can reach out and query all of the equipment on their side, but the traffic originating from my client's side will be dropped at the NOC NAT address.

As mine is set, the client always initiates the connection. The client is behind a NATed firewall, and the agency is absolutely NOT going to open a firewall port for inbound connections from my NOC to the VPN. So... the client has to initiate the connection to my NOC. Since my NOC WAN is dynamic, I had to tie it to a DynDNS hostname, which the client could then resolve to initiate a connection in the event my NOC WAN changed (does all the time...). Since hostname is static, but DNS resolution is dynamic, I don't have to change the client's router to re-establish a connection. I also allowed their security folks to be happy with the firewall remaining in place. Finally, my small NOC has the advantage of being able to float around address-wise and not have a single WAN address to be targeted by the a**holes out there.

As for routes, my NOC is aware of the address segment assigned to the equipment I'm monitoring on the Client's network. Simple static next hop route. Destination 192.168.XX.0/24, next hop 10.1.1.2. NAT rule translates traffic to the client to the 10.1.1.1 address, so all my client's network sees is my 10.1.1.1 vtun address querying equipment, and the equipment responds to that NAT address. Sneaky, but it works perfectly. The client's side only has the route to the NAT addresses that was automatically created with the VTUN. So... the client's routing table only shows destination 10.1.1.1&2/32 going to the interface vtunXX.

 

So comparing to my setup, I see the following:
I don't have the --user and --group tags even specified. Never needed them.
Next important thing is to leave the remote-host BLANK on the Land Lubber router. This is especially important if your Salty Sea router has a dynamic WAN IP address, or has any potential to change. If it has something in it, it may try to resolve and upon failure, it may deny the VPN.
Finally, I don't see any subnet mask specified for the local-address. Might be a good idea, since this is just the tunnel address.


Hope this makes sense. Typed up after a LONG day doing too much mountain work, so if it's fuzzy, that's how my brain is this evening.