What's new

Adding nat rules before any clients connect

  • Thread starter Deleted member 62525
  • Start date
  • 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!

D

Deleted member 62525

Guest
I am trying to figure out where is the best place to put a code that adds new ip rules and iptables before any clients connect and before any ovpnclient code execution. The nat-start is not blocking so this is a no go. I have put a call to my code in service-event and testing for $1=restart && $2= diskmon.

Any suggestions if this is correct or maybe there is a better place to invoke the code?
 
nat rules should go in nat-start and filter rules should go in firewall-start. What is the problem with doing it this way? If you make any changes before these scripts run they will just be wiped out.
 
Thanks but as I mentioned nat-start does not guarantees that your additional nat rules will be there before say ovpnclient starts. So obviously for some stubborn clients or apps that require these rules to connect this will be a no go scenario. My current solution works the way I expected and all additional nat rules and port forwards are there before any client apps connect. I am only wondering if what I have done is correct or is there a better way.
 
You need to use nat-start, otherwise any firewall restart will simply remove your rules.
 
You need to use nat-start, otherwise any firewall restart will simply remove your rules.

Hence my dilemma. The nat-start is non blocking and I noticed in a log that if I include nat rules eg: route add -net, it will not finish setting up before ovpnclient code executes. Would have been nice if the nat-start "was" blocking :) At this moment there is not real alternatives.

How do I make sure my additional nat rules are setup before any of the network clients connect and before any vpn connections are setup?
 
Hence my dilemma. The nat-start is non blocking and I noticed in a log that if I include nat rules eg: route add -net, it will not finish setting up before ovpnclient code executes. Would have been nice if the nat-start "was" blocking :) At this moment there is not real alternatives.

How do I make sure my additional nat rules are setup before any of the network clients connect and before any vpn connections are setup?
I really don't follow what you're saying. "route add -net" is not a NAT rule, it's routing. If you want to change the routing when the OpenVPN client starts you need to do it in the openvpn-event script.

I also don't understand when you say "before any of the network clients connect". An Ethernet client is connected to the router from the moment the router powers on. It can access the router as soon as it gets an IP address.

Maybe if you show us the script you're using it would be more apparent.
 
I really don't follow what you're saying. "route add -net" is not a NAT rule, it's routing. If you want to change the routing when the OpenVPN client starts you need to do it in the openvpn-event script.

I also don't understand when you say "before any of the network clients connect". An Ethernet client is connected to the router from the moment the router powers on. It can access the router as soon as it gets an IP address.

Maybe if you show us the script you're using it would be more apparent.

In my home network I have a Synology NAS connected to my RT86U. All my network clients use openvpn except for TV. Synology runs few apps that I need remote access. I would like to have this access to NAS apps regardless if openvpn client is active or not. My old setup was including port port forwarding rules in nat-start and specifically for plex server including " route plex.tv 255.255.255.255 192.168.0.1" in openvpn client config file. Without this command Plex would not receive Public IP. FYI - I have a double NAT situation.
In above setup everything works except as expected but if vpn client is not started this "route plex.tv 255.255.255.255 192.168.0.1" would not prepare certain routes that are necessary for Plex server to work and obtain Public IP. If that happens I loose remote access.

Removing "route plex.tv ... " from vpnclient configuration and moving it outside to say nat-start does not work since it will setup a route after vpn client activates. I tried it and I tell you it does not work, I have to manually refresh vpn client and then Plex would pickup Public IP.
This is why I posted a question about where is the best place to include this code "route add -net ... ". This will replace my old "route plex.tv" command in vpnclient configuration file and make sure this is in place before vpnclient activates (or not). This way I will always have remote access and Plex server will always have proper Public IP.
 
OK. So from what you've said this is nothing to do with NAT as such, it's purely a routing question?

The only NAT related thing is the port forwarding. But that's just the normal setup in the GUI.

When the VPN client is disabled there should be no particular requirement for your routing command as all the traffic will go through the default gateway. Or are you using some sort of VPN "kill switch" setup?
 
OK. So from what you've said this is nothing to do with NAT as such, it's purely a routing question?

The only NAT related thing is the port forwarding. But that's just the normal setup in the GUI.

When the VPN client is disabled there should be no particular requirement for your routing command as all the traffic will go through the default gateway. Or are you using some sort of VPN "kill switch" setup?

Thank you @ColinTaylor. Sometimes it takes someone to ask questions for a person to revise how they think or approach the problem.
My old config was correct and the issue is actually with the NAS. When vpnclient on the router is disconnected or changes state the Plex server remote access goes down. It basically refuses to re-open the connection. I have to investigate further on the NAS itself.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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