x3mRouting x3mRouting ~ Selective Routing for Asuswrt-Merlin Firmware

[Xentrk]

Good! Let me just like all of them

There's a problem that I can't debug, and it's not because of your script, but maybe something it's interfering.
When routing the traffic between vpn server to vpn client, all works good! However, after a few time (can't say how much. It can be 5 minutes or 24h), it's like the rules are deleted and when accessing via vpn server I can only access lan. To make it work I've to force a vpn client restart (maybe to make the rules being applied again).
It may be something, dont know what, that is deleting the rules, or something even weird that I cannot imagine.

My question/suggestion is - in this particular case, route vpn server to vpn client, is it possible to create a script that runs on cron each maybe 10-20 minutes, to check if the rules are there, or at least if the server->client route is working, and if not, apply the rules again?

It's weird and I tried everything to understand what's happening and I can't figure it out.

What's the command to check if the rules are there? Because they maybe are, but the route stops working? Or they maybe are gone and I don't know how to check.

Thanks!

I prefer to figure out what is deleting the rules first. One known problem is that a firewall restart will delete the PREROUTING rules but not the POSTROUTING rules. But the vpnserver to vpnclient only uses the POSTROUTING rules. Can you look at the system log for clues?

 

[maghuro]

I prefer to figure out what is deleting the rules first. One known problem is that a firewall restart will delete the PREROUTING rules but not the POSTROUTING rules. But the vpnserver to vpnclient only uses the POSTROUTING rules. Can you look at the system log for clues?

What will im looking for on system log?
Also is there a command to see what rules are set now? I can check after restart freshjr and see if the rules are still there. Maybe not.

 

[Xentrk]

IT'S FRESHJR_QOS FAULT!!!

If I apply or restart freshjr qos when the iptables rules for vpn server -> client are on, for some reason they're deleted/bypassed/something.

Can you look at this? Any way to prevent x3mRouting roules being deleted? For what I've seen it's out of my compreension range

Or... I have an idea... A script that runs WHEN someone connects to vpn server that checks if the rules are Applied, or simply re apply them!
I don't know however if vpn server has a when-user-connects event.

I'll look into it. I know the freshjr script also uses fwmarks/bitmarks. But last time I looked they differ from what x3mRouting uses.

 

[maghuro]

I'll look into it. I know the freshjr script also uses fwmarks/bitmarks. But last time I looked they differ from what x3mRouting uses.

I looked at it, but those marks and the next level for me, and it was like I was looking to something out of my compreension didn't figured it out by myself.

Thanks!!

 

[Xentrk]

I looked at it, but those marks and the next level for me, and it was like I was looking to something out of my compreension didn't figured it out by myself.

Thanks!!

I confirmed that a firewall restart does delete the POSTROUTING rule for the VPN Server to VPN Client routing. FreshJr script does a firewall restart and that is what is wiping out the rule. But what is strange is the other POSTROUTING MASQUERADE rules for the other interfaces don't get wiped out. Only the one for the VPN Server to VPN Client Routing.

I wonder if the firmware automatically runs the openvpn firwall scripts in /etc/openvpn/fw after a firewall restart to preserve the other MASQUERADE rules. This will require some analysis. Ideally, detecting the firewall restart would be the ideal solution. More thought and analysis is required.

 

[maghuro]

I confirmed that a firewall restart does delete the POSTROUTING rule for the VPN Server to VPN Client routing. FreshJr script does a firewall restart and that is what is wiping out the rule. But what is strange is the other POSTROUTING MASQUERADE rules for the other interfaces don't get wiped out. Only the one for the VPN Server to VPN Client Routing.

I wonder if the firmware automatically runs the openvpn firwall scripts in /etc/openvpn/fw after a firewall restart to preserve the other MASQUERADE rules. This will require some analysis. Ideally, detecting the firewall restart would be the ideal solution. More thought and analysis is required.

Nice catch! Yes, and every night the freshjr script restarts the firewall (or it checks if everythings ok, and if not, it restarts), so there's the culprit!
Maybe the firmware does run those firewall scripts. The question is, when you say that it doesn't delete the other rules, are you talking your script rules or other system rules?

 

[andresmorago]

I confirmed that a firewall restart does delete the POSTROUTING rule for the VPN Server to VPN Client routing. FreshJr script does a firewall restart and that is what is wiping out the rule. But what is strange is the other POSTROUTING MASQUERADE rules for the other interfaces don't get wiped out. Only the one for the VPN Server to VPN Client Routing.

I wonder if the firmware automatically runs the openvpn firwall scripts in /etc/openvpn/fw after a firewall restart to preserve the other MASQUERADE rules. This will require some analysis. Ideally, detecting the firewall restart would be the ideal solution. More thought and analysis is required.

i always wondered about this because everytime i performed something that reset the qos engine, x3mrouting died and had to restart it back again!
thanks for the confirmation

 

[Xentrk]

@RMerlin, what is your suggestion on how to handle the PREROUTING and POSTROUTING rules created by x3mRouting that get purged during a firewall restart? Should I place a copy of the rules in /jffs/scripts/firewall-start script?

Also, I am curious how the POSTROUTING MASQUERADE rules used by interfaces get reinstated. Do the fw scripts in /etc/openvpn/fw get run when the firwall is restarted?

Thank you!

 

[RMerlin]

@RMerlin, what is your suggestion on how to handle the PREROUTING and POSTROUTING rules created by x3mRouting that get purged during a firewall restart? Should I place a copy of the rules in /jffs/scripts/firewall-start script?

In which table? The content of the nat table are handled by nat_settings() not filter_settings(), so any change to these must be put in nat-start.

Also, I am curious how the POSTROUTING MASQUERADE rules used by interfaces get reinstated. Do the fw scripts in /etc/openvpn/fw get run when the firwall is restarted?

start_firewall() will also call run_ovpn_fw_script().

 

[Xentrk]

In which table? The content of the nat table are handled by nat_settings() not filter_settings(), so any change to these must be put in nat-start.

The PREROUTING fwmark/bitmask rules are in the mangle table for the routing of traffic to the appropriate interface based on contents of IPSET list.

The POSTROUTING MASQUERADE rules for the VPN Server to VPN Client or VPN Server to IPSET list are in the nat table.

Edit: I can move the start scripts back to nat-start to accommodate the firewall restart events if necessary. Over the past year, I started using the vpnclientX-route-up files as the script start-up location. I can still use the vpnclientX-route-pre-down to delete the routing rule when the tunnel goes down.

 

[RMerlin]

The PREROUTING fwmark/bitmask rules are in the mangle table for the routing of traffic to the appropriate interface based on contents of IPSET list.

The POSTROUTING MASQUERADE rules for the VPN Server to VPN Client or VPN Server to IPSET list are in the nat table.

Edit: I can move the start scripts back to nat-start to accommodate the firewall restart events if necessary. Over the past year, I started using the vpnclientX-route-up files as the script start-up location. I can still use the vpnclientX-route-pre-down to delete the routing rule when the tunnel goes down.

The mangle table is configured right after filter_settings(). Normally, firewall-start should be the correct place, however that's assuming nothing else directly calls mangle_settings(), bypassing firewall-start entirely. This might potentially happen with bwdpi for instance.

 

[andresmorago]

@Xentrk quick question
i see this error once in a while

Apr 21 15:08:46 RT-AC3100-0548 openvpn-event[26156]: Script not defined for event: vpnserver1-up

how can i fix it?

 

[maghuro]

@Xentrk quick question
i see this error once in a while

Apr 21 15:08:46 RT-AC3100-0548 openvpn-event[26156]: Script not defined for event: vpnserver1-up

how can i fix it?

That's not an error, it's an info message saying that there's no script defined for that action (vpnserver1-up)

 

[Luizlp10]

I can confirm that a firewall restart reset the rules, at list using the ASN method. I activated the https router webUI access page and the system performed a firewall restar(alongside disabling syslog). I noticed that in practice when I was not able to watch GLOBO(brazilian TV) anymore, but liststats still showed me the number of IPs. I had to delet every entry(GLOBO, NETFLIX, AMAZON) and then readd them again to work properly. Everything is fine now.

 

[andresmorago]

That's not an error, it's an info message saying that there's no script defined for that action (vpnserver1-up)

is there anything i should to in this case?

 

[maghuro]

is there anything i should to in this case?

Just have a cup of tea

 

[maghuro]

I can confirm that a firewall restart reset the rules, at list using the ASN method. I activated the https router webUI access page and the system performed a firewall restar(alongside disabling syslog). I noticed that in practice when I was not able to watch GLOBO(brazilian TV) anymore, but liststats still showed me the number of IPs. I had to delet every entry(GLOBO, NETFLIX, AMAZON) and then readd them again to work properly. Everything is fine now.

Xentrk is working on a workaround to prevent firewall resetting the rules

 

[Xentrk]

I can confirm that a firewall restart reset the rules, at list using the ASN method. I activated the https router webUI access page and the system performed a firewall restar(alongside disabling syslog). I noticed that in practice when I was not able to watch GLOBO(brazilian TV) anymore, but liststats still showed me the number of IPs. I had to delet every entry(GLOBO, NETFLIX, AMAZON) and then readd them again to work properly. Everything is fine now.

Placing the scripts in /jffs/scripts/nat-start using the example on the README page is the solution so the rules will get reinstated at boot or firewall restart. I will change the new version to do the same. I will still use the vpnclientX-route-pre-down to remove the routing rule if the client goes down.

 

[Xentrk]

Based on testing, this appears to be the best method to handle the routing rules for system restarts, firewall restarts and vpn client up/down events:

nat-start will be used to call the scripts at system boot and during a firewall restart. The iptables delete/append routing rules will get created and the appropriate entries stored in vpnclientX-route-up and vpnclientX-route-pre-down if they don't exist. This solves the issue of the routing rules being purged upon a firewall restart event.

The deletion of the iptables routing rules will be placed in vpnclientX-route-pre-down. This will purge the routing rules associated with the VPN Client if it is disabled.

The creation of the iptables routing rules will be placed in vpnclientX-route-up. This will create the routing rule for a VPN Client route-up event.

 

[maghuro]

Based on testing, this appears to be the best method to handle the routing rules for system restarts, firewall restarts and vpn client up/down events:

nat-start will be used to call the scripts at system boot and during a firewall restart. The iptables delete/append routing rules will get created and the appropriate entries stored in vpnclientX-route-up and vpnclientX-route-pre-down if they don't exist. This solves the issue of the routing rules being purged upon a firewall restart event.

The deletion of the iptables routing rules will be placed in vpnclientX-route-pre-down. This will purge the routing rules associated with the VPN Client if it is disabled.

The creation of the iptables routing rules will be placed in vpnclientX-route-up. This will create the routing rule for a VPN Client route-up event.

Perfect my friend!
Nothing more to say. Excellent job.
Can't wait for test the final version