OpenVPN server 2 (10.

[pekka]

Dear forum

Hopefully you can help me. This should be so simple but I have been stuck with this for 2 days now.
And I cannot be the one person wanting to do this.

I am running 386.1_2 on RT-AC86U and my goal is to setup 2 OpenVPN servers.

Server1 (ip pool: 10.8.0.0) : access to all LAN (192.168.1.*)
Server2 (ip pool: 10.16.0.0): access to singe static IP in LAN (192.168.1.6)

Both servers work now providing access to all LAN like show in IPv4 routing table.

The question is this simple, how do I change the routing so that all traffic from 10.16.0.0 goes to 192.168.1.6?

Thank you for helping a newbie.

Pekka

 

[L&LD]

@pekka welcome to the forums.

You haven't asked a question though, let alone give us any details of your hardware, firmware, or other aspects of your network that may be pertinent to a good reply.

 

[pekka]

@pekka welcome to the forums.

You haven't asked a question though, let alone give us any details of your hardware, firmware, or other aspects of your network that may be pertinent to a good reply.

@L&LD It seems than that I am failing in everything today ...apologies for accidentaly sending an uncomplete post. Hopefully completele message makes answering easier

 

[Martineau]

Dear forum

Hopefully you can help me. This should be so simple but I have been stuck with this for 2 days now.
And I cannot be the one person wanting to do this.

I am running 386.1_2 on RT-AC86U and my goal is to setup 2 OpenVPN servers.

Server1 (ip pool: 10.8.0.0) : access to all LAN (192.168.1.*)
Server2 (ip pool: 10.16.0.0): access to singe static IP in LAN (192.168.1.6)

Both servers work now providing access to all LAN like show in IPv4 routing table.

The question is this simple, how do I change the routing so that all traffic from 10.16.0.0 goes to 192.168.1.6?

Thank you for helping a newbie.

Pekka

Here is a firewall solution in lieu of a routing solution.

You probably should really put these in the OVPN chain (rather than directly into the FORWARD chain) when the OpenVPN server initialises, but try it as-as

modprobe xt_comment 

iptables -I FORWARD -s 10.16.0.0/24 -d 192.168.1.0/24 -i tun22 -o br0 -m comment --comment "VPN Block LAN" -j REJECT --reject-with icmp-port-unreachable
iptables -I FORWARD -s 10.16.0.0/24 -d 192.168.1.6/32 -i tun22 -o br0 -m state --state NEW -m comment --comment "VPN to LAN Resource" -j ACCEPT

 

[eibgrad]

iptables -I FORWARD -s 10.16.0.0/24 ! -d 192.168.1.6 -j REJECT

 

[pekka]

iptables -I FORWARD -s 10.16.0.0/24 ! -d 192.168.1.6 -j REJECT

Thank you @Martineau and @eibgrad OpenVPN iptables rules seems to be the right way forward and I can can see the change in routing table.
Unfortunatelly this also caused OpenVPN server not to start. I need to further study the iptables tomorrow.

 

[eibgrad]

It would help if you labeled these snapshots. They're so narrowly cropped (no column headings, nothing), it's not always obvious what we're looking at.

Is that a static route for 192.168.1.6 pointing to the tunnel of the OpenVPN server?! If so, why? If 192.168.1.6 is routable from within the LAN, then there's no need to configure static routing, least of all back to the tunnel's IP network. It's just a firewall issue.

 

[pekka]

It would help if you labeled these snapshots. They're so narrowly cropped (no column headings, nothing), it's not always obvious what we're looking at.

Is that a static route for 192.168.1.6 pointing to the tunnel of the OpenVPN server?! If so, why? If 192.168.1.6 is routable from within the LAN, then there's no need to configure static routing, least of all back to the tunnel's IP network. It's just a firewall issue.

After trying "iptables -I FORWARD -s 10.16.0.0/24 ! -d 192.168.1.6 -j REJECT" to OpenVPN CustomConfiguration (img: customconfiguration) I did see the changes in the Routing Table (Img: RoutingTable) but it also caused Open VPN Server failed to start error (img: OpenVPN_failedtostart).

 

[eibgrad]

The firewall rule does NOT go in custom config! It needs to be added as a firewall-start script!

 

[L&LD]

I think 2048 RSA Encryption is required.

 

[eibgrad]

Here's a link to an example of adding a firewall-start script (just change the rule).

NordVPN and DNS

Hello I was wondering IF I need to use Nordvpn's DNS servers or Can I use Cloudfare, Google or quad9 DNS servers. If yes how can I make this happen?

www.snbforums.com

 

[elorimer]

I think 2048 RSA Encryption is required.

Explain?

 

[L&LD]

@elorimer, I thought that was the default necessary from v2.5 (or v2.51) forward. (As weaker ciphers get removed with each update).

 

[pekka]

Here's a link to an example of adding a firewall-start script (just change the rule).

NordVPN and DNS

Hello I was wondering IF I need to use Nordvpn's DNS servers or Can I use Cloudfare, Google or quad9 DNS servers. If yes how can I make this happen?

www.snbforums.com

@eibgrad This is getting even more strange now.
With you help (and vi editor user manual) I was able to add the firewall rule to /jffs/scripts and the routing table now looks like in picture 1. Rule added OK.
But there is still the default rule in row three which gets pushed to OpenVPN client "add route 192.168.1.0/24 11 10.16..0.1" which means I am still able to access everything in 192.168.1.0. BUT when I make an OpenVPN client configuration "route-nopull route 192.168.1.6" everything is routed to 192.168.1.6 IP only. But I cannot take the risk that someone is smart enough will remote those 2 rows from clien configuration.
How to remove the default routing in row 3? Why the firewall rule does not work?

 

[eibgrad]

@eibgrad This is getting even more strange now.
With you help (and vi editor user manual) I was able to add the firewall rule to /jffs/scripts and the routing table now looks like in picture 1. Rule added OK.
But there is still the default rule in row three which gets pushed to OpenVPN client "add route 192.168.1.0/24 11 10.16..0.1" which means I am still able to access everything in 192.168.1.0. BUT when I make an OpenVPN client configuration "route-nopull route 192.168.1.6" everything is routed to 192.168.1.6 IP only. But I cannot take the risk that someone is smart enough will remote those 2 rows from clien configuration.
How to remove the default routing in row 3? Why the firewall rule does not work?

Ok, let's back up, because I have no idea what you're trying to do here. What's w/ this "add route 192.168.1.0/24 11 10.16..0.1", or "route-nopull route 192.168.1.6." None of that makes any sense.

Normally you set the access mode on the OpenVPN server to LAN only (or Both), and the server pushes the LAN (e.g., 192.168.1.0/24) to the OpenVPN client. That gives the client the routing and access to that network over the tunnel. But you wanted to restrict that access to only *one* device/IP, specifically 192.168.1.6, which can be done w/ the firewall rule I provided.

That's all you need! Not unless there's some other objective here that you haven't made clear.

 

[pekka]

Ok, let's back up, because I have no idea what you're trying to do here. What's w/ this "add route 192.168.1.0/24 11 10.16..0.1", or "route-nopull route 192.168.1.6." None of that makes any sense.

Normally you set the access mode on the OpenVPN server to LAN only (or Both), and the server pushes the LAN (e.g., 192.168.1.0/24) to the OpenVPN client. That gives the client the routing and access to that network over the tunnel. But you wanted to restrict that access to only *one* device/IP, specifically 192.168.1.6, which can be done w/ the firewall rule I provided.

That's all you need! Not unless there's some other objective here that you haven't made clear.

@eibgrad Thanks for your support and patience as well.
Target is to have 2 client access profies to my home network.
trough Server1 (ip pool: 10.8.0.0) : access to all LAN (192.168.1.0)
trough Server2 (ip pool: 10.16.0.0): access to singe static IP in LAN (192.168.1.6)
with the firewall rule now in place in /jffs/scripts/firewall-start
the routing table looks like picture1 in previous message (looks OK to me)

after connecting to trough Server 2 my client has IP address of: 10.16.0.2 (which is OK) but I can still access for example NAS in 192.168.1.75 so somehow the firewall rule is not working.

 

[eibgrad]

@eibgrad Thanks for your support and patience as well.
Target is to have 2 client access profies to my home network.
trough Server1 (ip pool: 10.8.0.0) : access to all LAN (192.168.1.0)
trough Server2 (ip pool: 10.16.0.0): access to singe static IP in LAN (192.168.1.6)
with the firewall rule now in place in /jffs/scripts/firewall-start
the routing table looks like picture1 in previous message (looks OK to me)

after connecting to trough Server 2 my client has IP address of: 10.16.0.2 (which is OK) but I can still access for example NAS in 192.168.1.75 so somehow the firewall rule is not working.

Well that part makes sense. But why it's not working, I have no idea. On the face of it, it's pretty simple. My biggest concern at this point is some of the strange things you've been adding to the custom config field in particular. But if everything else is working now except for this one remaining issue, then let's first check if the firewall rule even got applied.

iptables -vnL FORWARD

 

[pekka]

Problem SOLVED. Thanks @eibgrad and @L&LD

Just to conclude in case this will help some one else in the future.

After realising that best (and only?) way to update and vefify changes is from console ( I used PuTTY from WIn10) things started get smoother.
Using route and iptables -L commands you can really start to see what is happening.
And like already mentoined in this chain, add route is not needed in server side. In my case the only reason is to use it in client side to prevent all traffic going trough VPN server.

The final piece of infomration was mentioned by @L&LD "put these in the OVPN chain (rather than directly into the FORWARD chain)"
so solution was iptables -I OVPN -s 10.16.0.0/24 ! -d 192.168.1.6 -j REJECT

The only remaining mystery is why it did not work in FORWARD chain, but I can live with that

 

[eibgrad]

It should have worked in the FORWARD chain since it should have hit that rule long before the OVPN chain, but without being able to see the FORWARD chain in context, we're left to guess. Anyway, at least it's working.

 

[L&LD]

Just to clarify, I did not give that advice, but glad it fixed things for you.