Bidirectional communication only works with bridge on client

[astclair]

We use OpenVPN to provide a solution for our clients to connect multiple stores together for data replication, remote management, etc. 80% of the setups we deploy consist of a single Headquarters location running OpenVPN-AS, with multiple Remote Stores as clients. These Remote Store clients are using the built-in OpenVPN Client on Tomato firmware. Thus, the client gateway is the same device as the OpenVPN Client.

Now, in the past we could never get bi-directional communication to function without implementing a custom firewall script in the tomato firmware that bridges tun0 to WAN. Here is the gist of it:

Code: Select all

iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
iptables -t filter -I INPUT 1 -i tun0 --destination "$(ip a s br0 | grep 'inet ' | cut -d'/' -f1 | sed 's/^.*inet //')" -j ACCEPT

It runs via sh, hence the shell commands to pull the proper destination IP.

However, this causes a bit of headache when staging these routers to go out into the field. We do not want this to be bridged by default; only if the site needs bi-directional communication. So the current solution is just to copy/paste this script into the Firewall Scripts section of tomato, so that it gets run at startup and creates the bridge. Also, according to multiple documentations and Johan Draaisma (labeled as Senior support coordinator in the openvpn ticketing system):

I have several Access Server setups running right now, and I set one up a few days ago, whereby all I did after the initial configuration was the following. Perhaps this provides some insights.

VPN Settings > redirect all client internet traffic: no
VPN Settings > change DNS: no
VPN Settings > allow access to private subnets: no
Authentication > General > authentication mode: LOCAL
User Permissions > new user "site2site" with password xxxxxxxxx
User Permissions > site2site > allow access to (subnet behind Access Server) using ROUTING
User Permissions > site2site > VPN client gateway (subnet behind client)
User Permissions > site2site > autologin allowed
Advanced VPN > inter-client communication: yes

Then on the client I installed openvpn, put the autologin profile, and started the openvpn service.
I edited /etc/sysctl.conf and enabled the ipv4.ip_forward option and refreshed the sysctl settings so the ip forwarding gets enabled and will remain enabled after reboot.

I have followed these instructions to a T multiple times, but cannot achieve bi-directional communication without the firewall rule in-place. To rule out it being an odd issue with the Tomato firmware, I setup a test environment using two CentOS 7 machines, one as OpenVPN-AS and one as OpenVPN Client, and still found myself in the same spot.

On Tomato, I have not yet been successful in building the ipv4.ip_forward option into the firmware at compile-time, and I'm not really sure that I'm setting it properly via ssh either. I've found probably 8 different references listing the option in different locations. The method that seems most correct is

Code: Select all

echo 1 > /proc/sys/net/ipv4/ip_forward

. Most of the Tomato firmware is read-only after compilation, so I believe this will end up being an option that needs to be configured before building the firmware. It is running Linux kernel 2.6.22.19 with a mips processor.

Now, on to setup and configuration.

Headquarters:
Router: Asus RT-N16 running Shibby Tomato 1.28 v132
WAN: 12.34.56.78
LAN: 10.217.1.0/24
Gateway (Router IP): 10.217.1.1
OpenVPN-AS: 10.217.1.3
Static Route: Destination 10.217.2.0, Subnet 255.255.255.0, Gateway 10.217.1.3

OpenVPN-AS:
VPN Dynamic Pool: 5.5.1.0/24

Remote Store:
Router: Asus RT-N16 running Shibby Tomato 1.28 v132, OpenSSL 1.0.2d, OpenVPN Client 2.3.7
WAN: 23.45.67.89
LAN: 192.168.3.0/24
Gateway (Router IP): 192.168.3.1
OpenVPN Client: 192.168.3.1 (running on router)

OpenVPN-AS Config:
https://gist.githubusercontent.com/GFXD ... 44/as.conf

OpenVPN Client Config: (from .ovpn file)
https://gist.githubusercontent.com/GFXD ... lient.ovpn

I am a bit confused by these configs. The server file is as.conf located at /usr/local/openvpn_as/etc/as.conf and labels the version as 1.1. We have had this solution in place for a long while, so I believe this is an old config file. I'm not sure where to locate a more recent one? In the same directory, the VERSION file says AS_VERSION=2.0.21. Also, the client.ovpn file that's getting generated has some troubling settings. I've set the SSL Settings to require TLS 1.1, yet the .ovpn is still saying TLS 1.0 or highest.

Results: (without bridging Firewall script)
Ping from HQ router to RS router:


Ping from HQ router to PC on RS network:


tracert from PC on HQ network to PC on RS network:


Ping from RS router to HQ router:


Ping from RS router to PC on HQ network:


tracert from PC on RS network to PC on HQ network:


Results: (with Firewall script)
When I enable the Firewall rule posted above, the tracert from HQ PC to RS PC finally resolves:




What I've gathered:
It really seems like I'm just missing some simple rule on the Client side that automatically routes traffic pushed to it. If I have to bridge the connection then so be it, however that just feels like overkill.

Do any of you talented folks have any suggestions as to what I can try next?

Thanks,
Aaron St. Clair

[Traffic]

That is a well formatted post

Unfortunately, posted on the wrong board

This is the Access Server support page:
configuration-f25.html

I have notified the Mods and asked them if they could kindly move this post.

Also, we don't know a great deal about Tomato Firmware here .. so can't help a lot with that.
And Tomato is basically the problem it seems, as you must run it with some odd bridge setup
for it to pass packets from the LAN to the WAN .. which, as you say, feels like overkill ..

However, for your specific requirement I recommend you read these pages of the HOWTO:

• To understand the routing required: HOWTO: Expanding the scope of the VPN to include additional machines
• To route ALL client traffic: HOWTO: Routing all client traffic (including web-traffic) through the VPN

I realise they are not specifically intended for your system but they are the basis of how OpenVPN does the job.
Perhaps you can squeeze them kicking and screaming into the Tomato router/AS-Server and solve the problem.