Posted: Mon May 20, 2019 10:26 Post subject: How setup OpenVPN client on DD-WRT (Asus RT-N18U)?
Hi, how setup OpenVPN client?
I have *.ovpn file. I tried used this file with standard firmware Asus RT-N18U, I can connect to server. PC behind router can access to PC in OpenVPN Net. But I also need make access from PC in OpenVPN to PC behind router, I can't do it, so I decide use dd-wrt firmware.
I what make connect to my VPN with some features:
1. Auto connection to my OpenVpn server.
I have ovpn file, which I use when I try setup OpenVpn client with standard Asus firmware.
2. Make access from PC behind router to PC in VPN
3. Make access from PC in VPN to PC behind router
Like port forwarding? Or some else?
PC_1 behind router have ip 192.168.0.10
PC_2 behind router have ip 192.168.0.11
Router ip in VPN 10.10.0.38
Also I have PC, which connect to VPN and have ip 10.10.37, I want take access to 22 port to PC_1 192.168.0.10, use 10.10.0.38:122 and PC_2 10.10.0.38:222
4. All another traffic not to VPN must go over WAN not over VPN.
opvn file: (I deleted some part of private key):
remote 126.96.36.199 1500
Sounds to me like what you're after is a site-to-site configuration.
In order for devices on the local network behind the OpenVPN server to reach devices behind the OpenVPN client, you need three things.
1) To inform the OpenVPN client of the local network behind the OpenVPN server. Usually that's via a push directive in the OpenVPN server config. Since you didn't provide that information, I can't be more specific than x.x.x.0.
push "route x.x.x.0 255.255.255.0"
2) A route directive in the OpenVPN server config which specifies the local network behind the OpenVPN client.
route 192.168.0.0 255.255.255.0
3) An iroute directive in a file based on the common-name of the OpenVPN client that's placed in the CCD directory (on the *server* side).
iroute 192.168.0.0 255.255.255.0
It's this last requirement that ppl usually overlook.
Would using a bridged (TAP) setup not be the easier option?
You can't make that determination w/o having the context.
If I'm using a site-to-site configuration between my home and my brother-in-law's home, we probably have two different local networks on each side. It doesn't make sense to create a bridged (tap) tunnel under those circumstances. You just want to route between those two networks over the tunnel.
OTOH, let's pretend this is a business, who happens to have set up shop in two different building, perhaps just across town. If it wasn't for the fact of this physical separation, both offices would be using the same local network, have access to the same resources, etc. There's no sense in creating separate local networks in this case. You want a bridged (tap) tunnel so there is a seamless transition from one side of the tunnel to the other. Of course, you'd probably block DHCP across that tunnel so each side could still manage its own ISP.
IOW, unless you give me the context, the big picture, it's impossible to say whether you should be using a routed (tun) or bridged (tap) tunnel. And most of the time when ppl post problems in this forum, we have NO CLUE of that context. All we typically have is a predefined config, routed or bridged, and asked to make it work.