OpenVPN Server log, is this in error ?

[GSpock]

Hi all,
in the OpenVPN Server log file, I see the message below when a client is connecting:

Aug 28 11:52:30 ovpn-server2[15443]: client/192.168.1.1:52551 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.98.0 255.255.255.0 vpn_gateway 500,dhcp-option DNS 192.168.98.1,route 192.168.1.0 255.255.255.0,route-gateway 10.116.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.116.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)

Does "status=1" at the end, means that there is an error ?
Thx,
GS

 

[ColinTaylor]

Does "status=1" at the end, means that there is an error ?

No, that's the normal status code.

 

[GSpock]

Thanks ! @ColinTaylor
Nevertheless, despite the "route to 192.168.1.0", the (Win) client cannot see/access other 192.168.1.0/24 devices (whatever the setting LAN/Both on the server side).
GS

 

[ColinTaylor]

Try turning off the firewall on the target machine and then pinging it. Remember that the connection is NATed so the client's traffic will appear to be coming from 10.116.0.x.

 

[GSpock]

Thanks @ColinTaylor ; I realize that this is more complicated due to my set-up that I have not explained. Will review it, further test & come back if issue persists.

 

[eibgrad]

It's obvious from the PUSH_REPLY message that 192.168.1.0/24 is NOT the same LAN as the server (192.168.98.0/24). IOW, you're pushing the former *manually* in the custom config field. And that should work provided a) 192.168.1.0/24 is accessible from 192.168.98.0/24 even when NOT using the VPN, and b) there are no personal firewalls on the target devices preventing access by the OpenVPN server's tunnel (10.116.0.0/24).

When it comes to personal firewalls, it can be helpful to NAT the traffic from the tunnel as it's dropped on the local network, so the target believes the client is coming from its own local network (specifically the router) rather than the tunnel.

iptables -t nat -I POSTROUTING -s $(nvram get vpn_server2_sn)/$(nvram get vpn_server2_nm) -o br+ -j MASQUERADE

 

[GSpock]

Thank you @eibgrad
For clarity, this is my set-up:

1. main router is AX86U (192.168.1.1)
2. sub router is AX56U (192.168.98.1), WAN port is connected to LAN port of AX86U
3. AX56U runs OpenVPN Server1, TUN/UDP with "Client will use VPN to access" set to "LAN only" (excluded "both" for performances reasons), and with a specific push route command.

What I was trying to achieve is when connected via OpenVPN with PC (running W10), accessing other devices (TVShield, SMB shares, etc ...) connected to main LAN (192.168.1.0/24).
After several tests, and looking also in antoher of your post https://www.snbforums.com/threads/how-to-push-route-with-different-gateway.74845/#post-714467
I got the wished result by having this nat-start script on the AX56U:

#!/bin/sh
sleep 5
# make sure 192.168.1.0/24 is accssible from 98.x devices
iptables -I INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
iptables -I FORWARD -i tun21 -d 192.168.1.0/24 -j ACCEPT
exit

But I must admit that I am not completely understanding the role of each of those lines ...
and for completeness, the AX56U is connected to home plug that is turned on/off on demand (another suggestion of yours ). So a big thank you @eibgrad

Brgds,
GS

 

[eibgrad]

Thank you @eibgrad
For clarity, this is my set-up:

1. main router is AX86U (192.168.1.1)
2. sub router is AX56U (192.168.98.1), WAN port is connected to LAN port of AX86U
3. AX56U runs OpenVPN Server1, TUN/UDP with "Client will use VPN to access" set to "LAN only" (excluded "both" for performances reasons), and with a specific push route command.

What I was trying to achieve is when connected via OpenVPN with PC (running W10), accessing other devices (TVShield, SMB shares, etc ...) connected to main LAN (192.168.1.0/24).
After several tests, and looking also in antoher of your post https://www.snbforums.com/threads/how-to-push-route-with-different-gateway.74845/#post-714467
I got the wished result by having this nat-start script on the AX56U:

#!/bin/sh
sleep 5
# make sure 192.168.1.0/24 is accssible from 98.x devices
iptables -I INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
iptables -I FORWARD -i tun21 -d 192.168.1.0/24 -j ACCEPT
exit

But I must admit that I am not completely understanding the role of each of those lines ...
and for completeness, the AX56U is connected to home plug that is turned on/off on demand (another suggestion of yours ). So a big thank you @eibgrad

Brgds,
GS

Ahh, now I remember that prior situation.

The INPUT and FORWARD rules are necessary when using LAN only because when it says LAN only, it means LAN only! As in, only 192.168.98.0/24! If you introduce any other local IP networks (e.g., 192.168.1.0/24), the firewall will block access. OTOH, if you specify Both, the router's firewall is indiscriminate, and will allow basically anything to be routed via the VPN server, public or private. But some ppl don't want users having internet access, so you have to resort to those firewall rules above w/ LAN only.

As far as the NAT rule, that's to get around personal firewalls on the destination device itself. Some personal firewalls will NOT allow access by any private network other than the one on which that device is running (e.g., Windows). Not unless you reconfigure the personal firewall to permit the access. Alternatively, that NAT rule solves the problem by masking the OpenVPN client's IP address w/ that of the router's LAN ip (192.168.98.1), so those devices will accept it. But in your case, the access is NOT to the local IP network of 192.168.98.x, but 192.168.1.x, which lies upstream of the WAN. So that NAT rule is both ineffective and unnecessary in that particular configuration. The traffic from the OpenVPN server is already being NAT'd across the *WAN* of the secondary router, which is on the same IP network as the upstream target devices.

And btw, nat table and filter table rules should NOT be in the same script! Doing so can lead to truncation of your firewall rules! The only thing that should be in nat-start is nat rules. The INPUT and FORWARD chains (of the filter table) need to be in a firewall-start script.

Asus AC68-u iptable rule question

Awesome, I think this is a bit better then using dnsfilter. Maybe it works the same but I feel anything obviously is hardcoded to be force redirected. So primary rpi will be XX:XX mac and secondary rpi will be YY:YY mac? just double checking It doesn't matter the order or preference on these as...

www.snbforums.com