What's new

AsusWRT and OpenVPN works only one way.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

bortek

Occasional Visitor
I have had successful setup of OpenVPN in IPFIRE on my two separate locations setup. Lets call them SiteA and SiteB which are actually my two separate houses. SiteA acts like client and SiteB as server which actually in terms of OpenVPN is irrelevant since I am running it in net-to-net or site-to-site mode.

Now on SiteA I have replaced IPFIRE with Asus AC86U which runs AsusWRT. I have moved the config from IPFIRE to AsusWRT and setup a client connection from it. After some struggling with p12,certs,key,etc I managed to get the VPN up and running. So the VPn connection is now established fine.

Problem is that it works one way. From SiteB->SiteA it works fine but not the other way around.

I can see with tcpdump running on IPFIRE at SiteB that a test ping packet (sent from AsusWRT node) actually arrives into IPFIRE (on SiteB) and looks like this

10:35:58.922260 tun0 In IP 10.10.1.2 > 192.168.0.223: ICMP echo request, id 1577, seq 0, length 64

But then apparently it is not being forwarded for some reason to the dest host (in this case 192.168.0.223) . tcpdump on dest not does not receive anything even with firewalld turned off.

The routing table looks correct to me and looks line this on IPFIRE at SiteB

netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 178.78.202.129 0.0.0.0 UG 0 0 0 red0
10.10.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
178.78.YYY.XX 0.0.0.0 255.255.255.128 U 0 0 0 red0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 green0
192.168.1.0 10.10.1.2 255.255.255.0 UG 0 0 0 tun0

Keep in mind that if I connect back IPFIRE on SiteA then everything works just fine but not with AsusWRT.

I even tested on SiteA a frash install of raspbian,openvpn,same ovpn config and it does not work in the same manner as AsusWRT.

That makes me think that IPFIRE on SiteA (and IPFIRE in general) makes some tricks with the outgoing packets ?!? or with the routing on SiteA/B which I cannot see. For some reason onlu IPFIRE<->IPFIRE works.

Any ideas what this could be or what can I check or how else to troubleshoot?
 
Another finding is that pinging and tcpdumping shows different results when using ipfire IPFIRE(works) or AsusWRT(doesnt work) on SiteA.

There are 2 packets for for each request/response and from LAN ip when working and VPN/tunX IP when not working. Why?

ping SiteA(AsusWRT) -> SiteB(IPFIRE)
10:35:58.922260 tun0 In IP 10.10.1.2 > 192.168.0.223: ICMP echo request, id 1577, seq 0, length 64

ping SiteA(IPFIRE) -> SiteB(IPFIRE)
14:11:52.123255 tun0 In IP 192.168.1.1 > 192.168.0.223: ICMP echo request, id 10546, seq 1, length 64
14:11:52.123469 green0 Out IP 192.168.1.1 > 192.168.0.223: ICMP echo request, id 10546, seq 1, length 64
14:11:52.124664 green0 In IP 192.168.0.223 > 192.168.1.1: ICMP echo reply, id 10546, seq 1, length 64
14:11:52.124750 tun0 Out IP 192.168.0.223 > 192.168.1.1: ICMP echo reply, id 10546, seq 1, length 64
 
Does seem a bit unusual. 99% of the time, the problem w/ a site-to-site OpenVPN is the inability to initiate connections from the server side to the client (and usually because the user has overlooked a few details, like forgetting to consider iroute directive).

Only guess I can make at the moment is either the OpenVPN server isn't pushing a redirect-gateway directive to the OpenVPN client (if the intent is to make the server an internet gateway for the client), or isn't pushing its own local IP network to the client w/ a route directive, hence the client doesn't know how to route to that network. Of course, you could always add that route directly to the OpenVPN client config and see if it helps.

Code:
route 192.168.0.0 255.255.255.0 vpn_gateway

I assume 192.168.0.0/24 is the remote network on site B.

But I would have to assume each OpenVPN client is getting the exact same configuration push'd from the OpenVPN server. And for the ASUS OpenVPN client to NOT have those routes established on the client, it would have to explicitly reject them by using either the route-noexec or route-nopull directives. But that would NOT be something the OpenVPN client would do by default. It would require a deliberate act, or happen indirectly due to the selection of some GUI option.

Biggest problem for me is that I'm far more familiar w/ Merlin than ASUS OEM firmware. So I can only speculate.
 
I can flash merlin if that will make any difference. This is how server and client configs look like and you can see both nets. There is no push/pull involved, the routes are instead explicitly defined.

SiteB(IPFIRE) that acts like server
----------------------------------------
user nobody
group nobody
persist-tun
persist-key
script-security 2
remote myremote.org
float
ifconfig 10.10.1.1 10.10.1.2
route 192.168.1.0 255.255.255.0
up "/etc/init.d/static-routes start"
dev tun
status-version 1
status /var/run/openvpn/jarvastaden-n2n 10
port 12345
proto udp
tun-mtu 1500
fragment 1300
mssfix
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
verb 3
keepalive 10 60
daemon jarvastadenn2n
writepid /var/run/jarvastadenn2n.pid
management localhost 12345
-------------------------------------------------


SiteA(AsusWRT) acts as a client. Keep in mind that WRT converts the ovpn file that I input via GUI and the result is this one. I also tried to remove "client" directlive from /tmp/etc/openvpn/client2/config.ovpn
------------------------------------
remote myremote.org
resolv-retry 30
nobind
proto udp
port 12345
dev tun12
route-up '/etc/openvpn/ovpn-route-up'
route-noexec
sndbuf 0
rcvbuf 0
persist-tun
persist-key
up '/etc/openvpn/ovpn-up'
down '/etc/openvpn/ovpn-down'
setenv ovpn_type 1
setenv unit 2
setenv adns 1
setenv route_net_defdev wwan0
script-security 2
daemon vpnclient2
verb 4
status-version 2
status status 10

client

auth SHA512
cipher AES-256-CBC

ca ca.crt
cert client.crt
key client.key

script-security 2
float
ifconfig 10.10.1.2 10.10.1.1
route 192.168.0.0 255.255.255.0
status-version 1
tun-mtu 1500
fragment 1300
mssfix
remote-cert-tls server
tls-client
tls-version-min 1.2
keepalive 10 60
----------------------------------------

As yo can see WRT wants to do stuff differently and besides adding "client" directive it also wants to fix the routes using it's scripts. Fine as long as it works and when looking at routing tables they look pretty logical to me. But for some reason it does not work as it should.

Is it at all possible to setup site-to-site using AsusWRT?
 
Thanks for the dumps, esp. since I now see the problem.

I can only assume you manually configured that OpenVPN server config file, because some things don't make sense.

Code:
remote myremote.org
...
ifconfig 10.10.1.1 10.10.1.2
route 192.168.1.0 255.255.255.0
...
tls-server

You've configured the server w/ TLS (which is p2mp (point to multi-point)) but the ifconfig directive is configured for p2p (point-to-point) (i.e., static key).


Normally that ifconfig should be the subnet and netmask for the tunnel.

You can use the server directive (on the server side only, which acts like a macro) to have it generate the tls-server and appropriate ifconfig directives for you.

Code:
server 10.8.0.0 255.255.255.0

And that client is configured similarly. It's configured for tls-client, but it's also using a p2p ifconfig. In fact, there should be no ifconfig at all on the client side when using TLS. The server will determine its own local IP on the tunnel, and the IP assigned to the remote client(s) on their side of the tunnel at the time the connection is established (i.e., dynamically).

The remote directive on the server side is also only for p2p connections, NOT tls. TLS connections require clients to remotely contact servers, NOT the other way around.

Also, the server should be pushing its own network to the client.

Code:
push "route 192.168.0.0 255.255.255.0"

And the client should NOT be using route-noexec. Not unless it's perhaps using routing policy to process the route directives via its own scripts.

In a nutshell, the config is messed up w/ a variety of mismatched directives on each side.
 
Last edited:
I hasten to add, there's nothing wrong w/ using a p2p (static key) connection between the two sides, rather than TLS, just so long as you understand its stengths and weaknesses, as that link I provided explains. One thing it doesn't mention is that using a p2p/static-key connection makes configuring the access from site B to site A easier, since it only can and needs to support *one* p2p connection at a time. For p2mp (TLS), because many different clients could be connecting, each w/ their own unique local network, things become ambiguous for the server, and so you need to deal w/ the issue of iroute directives on the server side.


If you haven't figured it out already, OpenVPN can get very complicated, esp. if you have to do any of the configuration manually. Incredibly easy to make mistakes.
 
Last edited:
I know it's a and I must admit that these configs are not manually created. I have used IPFIRE GUIto setup net2net server side which produced the above mentioned config file. It also produced a client side config file which I download from IPFIRE, add use it as an input to AsusWRT GUI where I setup OpenVPN client. AsusWRT then generates the above mentioned client side config.

Honestly the whole official OpenVPN documentation is ambiguous and complex. I could not find a single standard documented way of setting up net2net config. There are various howtos on how to do it all over the places done by various people. And not surprisingly they are all very different from each other. So I am still sitting clueless after 2 weeks of playing around with it to no avail.

If you know of a guide/working net2net guide please do let me know.

Now I have followed static key guide setup you linked and created these configs. The VPN is established but there is no communication at all from neither side when I try to reach nodes using IPs of 192.168.0.0 and 192.168.1.0 networks.

server side
----------------------
user nobody
group nobody
persist-tun
persist-key
ifconfig 10.10.1.1 10.10.1.2
dev tun
port 12345
proto udp
secret /var/ipfire/ovpn/certs/ta.key
cipher AES-256-CBC
auth SHA512
verb 4
keepalive 10 60
daemon myserver
----------------------

client side
----------------------
remote myexample.com 12345
persist-tun
persist-key
proto udp
dev tun
ifconfig 10.10.1.2 10.10.1.1
route 192.168.0.0 255.255.255.0
keepalive 10 60
auth SHA512
cipher AES-256-CBC

<secret>
-----BEGIN OpenVPN Static key V1-----
XXX
</secret>

----------------------
 
Well that looks a LOT better. I'm not sure why the static key isn't inline on the server side too, just like the client, but whatever, as long as each side is using the same key, it should work.

Realize that for site-to-site, each side needs to have route directives that tell it what's available on the other side of the tunnel, NOT just a single route directive on the client side that says to route 192.168.0.0/24 over the VPN. IOW, the server also needs to know how to route back to the local network(s) behind the client's side of the tunnel. The only way it would otherwise work is if you NAT'd the tunnel on the client side. But in a site-to-site configuration, that wouldn't be typical or recommended.

There may be issues w/ firewalls too. But I haven't a clue what your situation is in that regard.

P.S. Remember, this is a p2p type of connection, so there's a lot of symmetry in how each side is configured. You could even have each side configured w/ a remote directive! IOW, either side could initiate the contact and establish the connection. There is no real "client" vs. "server" in this type of configuration. We're just using that terminology to help identify one side from the other (using "site A" vs. "site B" would be more appropriate). They are truly peers, in every sense of the term.
 
Last edited:
thanks for your input. To clarify my setup , I run OpenVPN inside routers (AsusWRT and IPFIRE) on both sites. Therefore "end user nodes" like PC, servers, etc on each site do not need any special adjustments to their routing tables ow since default route already know that that traffic needs to be routed via VPN tunnel.
 
thanks for your input. To clarify my setup , I run OpenVPN inside routers (AsusWRT and IPFIRE) on both sites. Therefore "end user nodes" like PC, servers, etc on each site do not need any special adjustments to their routing tables ow since default route already know that that traffic needs to be routed via VPN tunnel.

I agree, and I wasn't suggesting they do. I'm talking about the routers, which are hosting the VPN on each side. *THEY* need to know how to route between the local networks on each side of the tunnel, on behalf of the devices that are communicating between those same networks. So far, only the client knows about what lies behind the server. What about the server knowing what lies behind the client??
 
Update. I managed to get it to work. Started off with minimal config and expanded it with ifconfig and push routes. Now this might not look completely correct according to the OpenVPN docs but it works and does what I need.

Server config (IPFIRE)
dev tun
# 10.1.0.1 is our local VPN endpoint (office).
# 10.1.0.2 is our remote VPN endpoint (home).
ifconfig 10.1.0.1 10.1.0.2
route 192.168.1.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
push "route 10.1.0.0 255.255.255.0"

tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem

cipher AES-256-CBC
auth SHA512
port 22333

user nobody
group nobody
persist-tun
persist-key

verb 3

daemon jarvastadenn2n
keepalive 10 60



AsusWRT - AC86U as a client. I supplied this config (see below what Asus turned it into)
dev tun
remote example.com
port 22333

# 10.1.0.2 is our local VPN endpoint (home).
# 10.1.0.1 is our remote VPN endpoint (office).
ifconfig 10.1.0.2 10.1.0.1

tls-client
cipher AES-256-CBC
auth SHA512
persist-tun
persist-key
verb 3


<ca>
XX
</ca>

<cert>
YY
</cert>
<key>
ZZ
</key>



AsusWRT turned above client config into this one
cat /etc/openvpn/client1/config.ovpn

# Automatically generated configuration

# Tunnel options
remote example.com
resolv-retry 30
nobind
proto udp
port 22333
dev tun11
route-up '/etc/openvpn/ovpn-route-up'
route-noexec
sndbuf 0
rcvbuf 0
persist-tun
persist-key
up '/etc/openvpn/ovpn-up'
down '/etc/openvpn/ovpn-down'
setenv ovpn_type 1
setenv unit 1
setenv adns 1
setenv route_net_defdev wwan0
script-security 2
daemon vpnclient1
verb 3
status-version 2
status status 10

# Client Mode
client

# Data Channel Encryption Options
auth SHA512
cipher AES-256-CBC

# TLS Mode Options
ca ca.crt
cert client.crt
key client.key

# Custom Configuration
ifconfig 10.1.0.2 10.1.0.1
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top