Port forwarding with openVPN running

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page Previous  1, 2
Author Message
manthis
DD-WRT Novice


Joined: 11 Oct 2015
Posts: 9

PostPosted: Fri Oct 16, 2015 9:39    Post subject: Reply with quote
eibgrad wrote:

One way to get around it is to not allow devices that need remote access over the WAN to simultaneously initiate outbound connections from the LAN and over the VPN. IOW, exclude those IPs from the VPN. The GUI has a field called Policy Based Routing for this purpose. Once you add an IP or group of IPs to that field, the VPN is no longer the default gateway, and only those IPs listed in the policy based routing field will use the VPN.


Ok what I did is enable policy based routing for all my dhcp clients (192.168.1.224/27) in openvpn client configuration. So now my server is reaching wan with my regular ip address and all my dhcp clients on network 192.168.1.224/27 are going out through my VPN.

I could have supposed I would be able to reach my server easily from outside (wan) now, but it's still not working. Does anyone have a clue on how to solve the problem? Or at least how to debug?
Sponsor
Rafkat
DD-WRT Novice


Joined: 20 Dec 2011
Posts: 24

PostPosted: Fri Oct 16, 2015 17:25    Post subject: Reply with quote
eibgrad wrote:
As I alluded to previously, this is expected behavior because your routing tables and firewall rules are in conflict. The routing system is stateless and doesn't care about the history of related packets. But the firewall is stateful and does. In a perfect world, it wouldn't matter if the incoming packets from remote access over the WAN resulted in reply packets back out the VPN. But we live in a less than perfect world of firewalls that prevent this from happening.

So none of this can be corrected by mere firewall rules unless you were willing to drop the firewall. Even then, upstream firewalls such as that of the ISP may prevent it as well.

One way to get around it is to not allow devices that need remote access over the WAN to simultaneously initiate outbound connections from the LAN and over the VPN. IOW, exclude those IPs from the VPN. The GUI has a field called Policy Based Routing for this purpose. Once you add an IP or group of IPs to that field, the VPN is no longer the default gateway, and only those IPs listed in the policy based routing field will use the VPN.

Now sometimes ppl don’t like this limitation. They want *some* of the traffic for a local IP to use the WAN, and other traffic to use the VPN. And while it can be done, it gets a LOT more complicated, because now you need to qualify your routing based not just on IP, but also ports (or other criteria). And that means scripting your own policy based routing to replace that of the GUI. And that process requires that you create an alternate routing table, mark packets in the mangle table that meet that criteria, and add ip rules that tell the routing system to use that alternate routing table whenever it sees those marked packets.

That’s why this isn’t going to be corrected w/ a simple firewall rule or two. The only thing that determines how something is going to be routed is the routing system, specifically the routing tables. The only thing we can do w/ the firewall is mangle packets in such a way that the routing system treats them differently, namely, send some packets to the main routing table w/ one default gateway, and other packets to a second/alternate routing table w/ a different default gateway.

I have a example script for this purpose on PasteBin. It’s rather elaborate because it’s intended to serve a wide variety of purposes, but it illustrates the fundamental principles I’ve just described.

http://pastebin.com/f4rkPpu3

I have seen similar but far more stripped down versions of this type of script on the ‘net, often from VPN providers who are trying to solve this same problem for their customers. If I can find one of them, I’ll post back.

This is why I strongly encourage ppl to just not create a situation where you need both remote access and the initiation of outbound connections from the same local IP. It just makes things whole lot easier. But if you insist on it, you’ll need to code up your own policy based routing, similar to what I’ve done in that script.

P.S. Another way to force the use of the WAN for replies from remote access is by adding a specific route via the WAN to the public source IP of that remote access in the main routing table. That works because the routing system always prefers more specific routing instructions over more generalized ones, with the default gateway being the MOST generalized. Problem is, most times you don’t know the public IP from which you’ll be doing your remote access, making this more theoretical than practical. But if you’re lucky enough to have this situation (e.g., you always did your remote access from work w/ a well-known public IP), it would work.


@eibgrad Thanks for the script and reply.
I'm trying to run it but get Permission denied on this string:
VPN_IF="$(grep -Em1 '^dev ' /tmp/openvpncl/openvpn.conf 2> /dev/null | \ awk '{print $2}')"

Could you pls advice hot to run it properly?

Thank you.
manthis
DD-WRT Novice


Joined: 11 Oct 2015
Posts: 9

PostPosted: Fri Oct 16, 2015 20:04    Post subject: Reply with quote
Ok, got some news.

Now by setting up policy based routing for my dhcp machines, my server (whose ip address is in another range of ip address which are not redirected through the VPN) is finally accessible from WAN.

I can access it from any machine... BUT...
I can't access it from the machines which are redirected to the VPN tunnel:(
If I give to my machine an IP outside the policy based routing ip range I configured, I can access my http/https server with no problem so port forwarding seems to work fine.

If I look into the log files, it seems packet are dropped:
Code:

Oct 16 19:55:36 dd-wrt kern.warn kernel: DROP IN=vlan2 OUT= MAC=a0:63:91:30:dd:6b:00:17:10:85:e5:5d:08:00:45:00:01:79 SRC=108.160.170.45 DST=78.126.182.247 LEN=377 TOS=0x00 PREC=0x00 TTL=50 ID=49423 PROTO=TCP SPT=443 DPT=55468 SEQ=2956292386 ACK=300469110 WINDOW=43 RES

Why are they dropped? Can anyone help? I'm almost there Wink
Rafkat
DD-WRT Novice


Joined: 20 Dec 2011
Posts: 24

PostPosted: Sat Oct 17, 2015 0:42    Post subject: Reply with quote
@eibgrad script works perfectly fine. Thx again!
James2k
DD-WRT Guru


Joined: 23 Oct 2011
Posts: 549

PostPosted: Sun Nov 27, 2016 8:39    Post subject: Reply with quote
I know this is an old thread, but I'm having the same "problem". I've recently implemented OpenVPN at the router level and am using policy routing to send cetrain IPv4 traffic through my VPN on a few LAN clients, however one of the clients is hosting IIS Remote Access Gateway and Apache Proxy and I'd like to keep the NAT IPv4 port forwarding working. This script seems to be what I'm after, selectively marking such traffic for the WAN rather than VPN with fmark.

Could anyone point me in the right direction as to what iptables rules I need for this. I see there are example rules in the script but I can't seem to adapt for my purposes.

I also found a similar concept here:

http://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/

Any help would be appreciated!

Thanks!

_________________
James

Main router:

Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac

IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset

Easy ipset support for the R7000

VPN speed: Download: 77.96 Mbps Upload: 5.00 Mbps (AES-128-CBC HMAC-SHA1)

Yes you can get 50 Mbps+ with OpenVPN on a R7000 if you configure it properly!

Previous routers:

ASUS RT-N66U - The Dark Knight
WNR2000v3 - Bought on the cheap for someone else, neutered crap
WNR3500Lv1 - First venture into the DD-WRT world
James2k
DD-WRT Guru


Joined: 23 Oct 2011
Posts: 549

PostPosted: Fri Dec 02, 2016 8:36    Post subject: Reply with quote
eibgrad wrote:
James2k wrote:
I know this is an old thread, but I'm having the same "problem". I've recently implemented OpenVPN at the router level and am using policy routing to send cetrain IPv4 traffic through my VPN on a few LAN clients, however one of the clients is hosting IIS Remote Access Gateway and Apache Proxy and I'd like to keep the NAT IPv4 port forwarding working. This script seems to be what I'm after, selectively marking such traffic for the WAN rather than VPN with fmark.

Could anyone point me in the right direction as to what iptables rules I need for this. I see there are example rules in the script but I can't seem to adapt for my purposes.

I also found a similar concept here:

http://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/

Any help would be appreciated!

Thanks!


It's like any other traffic you want to force back over the WAN. You need to specify those parameters that will correctly identify the replies from these services when they reach the router (ip, protocol, port, etc.). So let's say you were port forwarding to a web server on the LAN (ip 192.168.1.100, port 80). You would specify:

$IPT_LAN -p tcp -s 192.168.1.100 --sport 80 $IPT_MARK # port forward

The reply packets will contain these values, which then get marked and routed over the WAN rather than the VPN.


Thanks for your reply, in the end I decided to add an additional local IPv4 address and set IIS to bind to this IP instead and then updated the port forward rules to point to the new local IPv4 address, which isn't listed in the policy routing section of the OpenVPN client config. This works fine.

The one other area I am having problem with is a client within the policy routing rules has traffic locally on TCP 4242 being forwarded externally to TCP 4719, but because of the VPN, it goes through the VPN gateway and not the WAN. Will similar iptables rules be able to stop this from happening also? I wasn't sure if the source port and destination port being different is an issue? It seems even though I've set the application in question to bind to an IP outside of policy routing, the traffic ultimately ends up going through the VPN gateway still, but I guess this makes sense as the primary IP of this box is having all traffic routed from the VPN.

_________________
James

Main router:

Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac

IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset

Easy ipset support for the R7000

VPN speed: Download: 77.96 Mbps Upload: 5.00 Mbps (AES-128-CBC HMAC-SHA1)

Yes you can get 50 Mbps+ with OpenVPN on a R7000 if you configure it properly!

Previous routers:

ASUS RT-N66U - The Dark Knight
WNR2000v3 - Bought on the cheap for someone else, neutered crap
WNR3500Lv1 - First venture into the DD-WRT world
James2k
DD-WRT Guru


Joined: 23 Oct 2011
Posts: 549

PostPosted: Fri Dec 02, 2016 15:54    Post subject: Reply with quote
eibgrad wrote:
James2k wrote:
eibgrad wrote:
James2k wrote:
I know this is an old thread, but I'm having the same "problem". I've recently implemented OpenVPN at the router level and am using policy routing to send cetrain IPv4 traffic through my VPN on a few LAN clients, however one of the clients is hosting IIS Remote Access Gateway and Apache Proxy and I'd like to keep the NAT IPv4 port forwarding working. This script seems to be what I'm after, selectively marking such traffic for the WAN rather than VPN with fmark.

Could anyone point me in the right direction as to what iptables rules I need for this. I see there are example rules in the script but I can't seem to adapt for my purposes.

I also found a similar concept here:

http://www.snbforums.com/threads/port-forward-while-using-vpn-client.28014/

Any help would be appreciated!

Thanks!


It's like any other traffic you want to force back over the WAN. You need to specify those parameters that will correctly identify the replies from these services when they reach the router (ip, protocol, port, etc.). So let's say you were port forwarding to a web server on the LAN (ip 192.168.1.100, port 80). You would specify:

$IPT_LAN -p tcp -s 192.168.1.100 --sport 80 $IPT_MARK # port forward

The reply packets will contain these values, which then get marked and routed over the WAN rather than the VPN.


Thanks for your reply, in the end I decided to add an additional local IPv4 address and set IIS to bind to this IP instead and then updated the port forward rules to point to the new local IPv4 address, which isn't listed in the policy routing section of the OpenVPN client config. This works fine.

The one other area I am having problem with is a client within the policy routing rules has traffic locally on TCP 4242 being forwarded externally to TCP 4719, but because of the VPN, it goes through the VPN gateway and not the WAN. Will similar iptables rules be able to stop this from happening also? I wasn't sure if the source port and destination port being different is an issue? It seems even though I've set the application in question to bind to an IP outside of policy routing, the traffic ultimately ends up going through the VPN gateway still, but I guess this makes sense as the primary IP of this box is having all traffic routed from the VPN.


The one other area I am having problem with is a client within the policy routing rules has traffic locally on TCP 4242 being forwarded externally to TCP 4719, but because of the VPN

I don't follow what you're saying here. You seem to be suggesting one is a source port and the other is a destination port. But without any context, I can't tell.

Again, from the perspective of the script, all it's doing is checking if the parameters match, and if they do, marking it. It's that simple. If you want to redirect any packets, whatever the circumstances, it's up to YOU to determine what those packets will look like once they reach the router and are analyzed. So there's no real magic here. It's pretty straight-forward. Match, you get redirected, no match, it's not redirected.

As far as policy based routing, do NOT use the GUI policy based routing and this script at the same time! This script is itself an implementation of policy based routing. It just happens to be more capable because you can chose other parameters besides source IP. But you can use simple source IP w/ the script as well. If you did use the GUI and this script together, they'd probably step on one another.


TCP 4242 is the port running on the server on the LAN, which externally forwards to TCP 4719, under normal circumstances it goes via the WAN, now it goes through the VPN, so I was clarifying if its possible to mark this traffic when the dport and sport is different, based on your response this appears possible, would it require multiple iptables rules to achieve given the different dport and sport?

Yes, this script will break if you use policy routing already, I would be implementing a specific routing table similar to the example I mentioned above, which does the same thing, just your script is more comprehensive along with the iptables examples.

_________________
James

Main router:

Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac

IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset

Easy ipset support for the R7000

VPN speed: Download: 77.96 Mbps Upload: 5.00 Mbps (AES-128-CBC HMAC-SHA1)

Yes you can get 50 Mbps+ with OpenVPN on a R7000 if you configure it properly!

Previous routers:

ASUS RT-N66U - The Dark Knight
WNR2000v3 - Bought on the cheap for someone else, neutered crap
WNR3500Lv1 - First venture into the DD-WRT world
James2k
DD-WRT Guru


Joined: 23 Oct 2011
Posts: 549

PostPosted: Sun Dec 04, 2016 8:25    Post subject: Reply with quote
Managed to figure it out. I needed to use the following iptables rules to make certain traffic use the WAN, for outbound services:

Code:
iptables -t mangle -I PREROUTING -i br0 -d x.x.x.x/24 -j MARK --set-mark 1
iptables -t mangle -I PREROUTING -i br0 -d x.x.x.x -j MARK --set-mark 1

_________________
James

Main router:

Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac

IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset

Easy ipset support for the R7000

VPN speed: Download: 77.96 Mbps Upload: 5.00 Mbps (AES-128-CBC HMAC-SHA1)

Yes you can get 50 Mbps+ with OpenVPN on a R7000 if you configure it properly!

Previous routers:

ASUS RT-N66U - The Dark Knight
WNR2000v3 - Bought on the cheap for someone else, neutered crap
WNR3500Lv1 - First venture into the DD-WRT world
atomicamp
DD-WRT User


Joined: 16 Apr 2018
Posts: 73
Location: Milwaukee

PostPosted: Sun Nov 11, 2018 12:51    Post subject: Reply with quote
eibgrad wrote:
As I alluded to previously, this is expected behavior because your routing tables and firewall rules are in conflict. The routing system is stateless and doesn't care about the history of related packets. But the firewall is stateful and does. In a perfect world, it wouldn't matter if the incoming packets from remote access over the WAN resulted in reply packets back out the VPN. But we live in a less than perfect world of firewalls that prevent this from happening.

So none of this can be corrected by mere firewall rules unless you were willing to drop the firewall. Even then, upstream firewalls such as that of the ISP may prevent it as well.

One way to get around it is to not allow devices that need remote access over the WAN to simultaneously initiate outbound connections from the LAN and over the VPN. IOW, exclude those IPs from the VPN. The GUI has a field called Policy Based Routing for this purpose. Once you add an IP or group of IPs to that field, the VPN is no longer the default gateway, and only those IPs listed in the policy based routing field will use the VPN.

Now sometimes ppl don’t like this limitation. They want *some* of the traffic for a local IP to use the WAN, and other traffic to use the VPN. And while it can be done, it gets a LOT more complicated, because now you need to qualify your routing based not just on IP, but also ports (or other criteria). And that means scripting your own policy based routing to replace that of the GUI. And that process requires that you create an alternate routing table, mark packets in the mangle table that meet that criteria, and add ip rules that tell the routing system to use that alternate routing table whenever it sees those marked packets.

That’s why this isn’t going to be corrected w/ a simple firewall rule or two. The only thing that determines how something is going to be routed is the routing system, specifically the routing tables. The only thing we can do w/ the firewall is mangle packets in such a way that the routing system treats them differently, namely, send some packets to the main routing table w/ one default gateway, and other packets to a second/alternate routing table w/ a different default gateway.

I have a example script for this purpose on PasteBin. It’s rather elaborate because it’s intended to serve a wide variety of purposes, but it illustrates the fundamental principles I’ve just described.

http://pastebin.com/f4rkPpu3

I have seen similar but far more stripped down versions of this type of script on the ‘net, often from VPN providers who are trying to solve this same problem for their customers. If I can find one of them, I’ll post back.

This is why I strongly encourage ppl to just not create a situation where you need both remote access and the initiation of outbound connections from the same local IP. It just makes things whole lot easier. But if you insist on it, you’ll need to code up your own policy based routing, similar to what I’ve done in that script.

P.S. Another way to force the use of the WAN for replies from remote access is by adding a specific route via the WAN to the public source IP of that remote access in the main routing table. That works because the routing system always prefers more specific routing instructions over more generalized ones, with the default gateway being the MOST generalized. Problem is, most times you don’t know the public IP from which you’ll be doing your remote access, making this more theoretical than practical. But if you’re lucky enough to have this situation (e.g., you always did your remote access from work w/ a well-known public IP), it would work.


So before I start my next 20 hours studying something that I may or may not have to fully comprehend, I am wondering if all of this applies if your VPN service provider allows port forwarding from the vpn. For example, I am using Mullvad VPN, and they allow port forwarding of ports that they choose for you at random. In other words, you can only request port forwarding, they pick the port number. So for example, I am using my DD-WRT router to force all LAN traffic through the router, and am using the following VPN firewall/killswitch suggested directly by you.

# allow only outbound connections to the VPN (no inbound)
iptables -I INPUT -i tun0 -m state --state NEW -j DROP
iptables -I FORWARD -i tun0 -m state --state NEW -j DROP
iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE
# block all access to the WAN by the LAN
WAN_IF="$(route -n | awk '/^0.0.0.0/{wif=$NF} END {print wif}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT

Now, If I I go to the mullvads status page and forward one of my ports, https://monosnap.com/file/0vqes4YHenPjEjgu0tA4dqfvVILNIj lets say Mullvad gives me 24705 as a port.

I'm assuming that no matter what I have to somehow unblock that port in my firewall by editing "# allow only outbound connections to the VPN (no inbound) ". Could you give me an example of how to allow incoming connections through the VPN from just that port in my firewall?

What I am trying to achieve, is running a Wordpress web server from my home, out into the public, for anyone to browse the website.

With that being said, my next question is, what exactly is this forwarding? Is this essentially forwarding a port from mullvads server and opening a port in their firewall for me to use? If that is the case, I'm also assuming that I must forward the open port from mulled (24705) to the local port that my web server uses (80,443 etc.). Is there a way to route an open port from my VPN to a different port in my LAN? Specifically one that My web server uses?

Must I forward port 24705 in my router firewall as well as my ISP router then too? Or are those open ports from Mullvad tunneled through the vpn? I'm not sure really where to start with all of this. Just trying to understand and figure out how to run a website while using a vpn dowrt router. Please let me know if you have any suggestions or input here! I dearly appreciate it!

Thanks!
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 5907
Location: Netherlands

PostPosted: Sun Nov 11, 2018 15:38    Post subject: Reply with quote
atomicamp wrote:

So before I start my next 20 hours studying something that I may or may not have to fully comprehend, I am wondering if all of this applies if your VPN service provider allows port forwarding from the vpn.


Short answer: no Sad

Your problem is hopefully easier to solve.

So I think it is better to start a new thread stating your problem and start with router model and firmware build. (You already did in the Broadcom forum, but this is indeed a more appropiate place Smile )

The firewall rules you were referring too are obsolete and seem wrong for your situation.

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Wireguard server setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1183135
Wireguard client setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624
Wireguard Advanced setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324787
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
atomicamp
DD-WRT User


Joined: 16 Apr 2018
Posts: 73
Location: Milwaukee

PostPosted: Mon Nov 12, 2018 0:35    Post subject: Reply with quote
egc wrote:
atomicamp wrote:

So before I start my next 20 hours studying something that I may or may not have to fully comprehend, I am wondering if all of this applies if your VPN service provider allows port forwarding from the vpn.


Short answer: no Sad

Your problem is hopefully easier to solve.

So I think it is better to start a new thread stating your problem and start with router model and firmware build. (You already did in the Broadcom forum, but this is indeed a more appropiate place Smile )

The firewall rules you were referring too are obsolete and seem wrong for your situation.


Thanks @EGC, new post HERE: Mullvad VPN / Port Forwarding vpn to router, proper firewall
atomicamp
DD-WRT User


Joined: 16 Apr 2018
Posts: 73
Location: Milwaukee

PostPosted: Sun Nov 18, 2018 21:12    Post subject: Reply with quote
eibgrad wrote:
As I alluded to previously, this is expected behavior because your routing tables and firewall rules are in conflict. The routing system is stateless and doesn't care about the history of related packets. But the firewall is stateful and does. In a perfect world, it wouldn't matter if the incoming packets from remote access over the WAN resulted in reply packets back out the VPN. But we live in a less than perfect world of firewalls that prevent this from happening.

So none of this can be corrected by mere firewall rules unless you were willing to drop the firewall. Even then, upstream firewalls such as that of the ISP may prevent it as well.

One way to get around it is to not allow devices that need remote access over the WAN to simultaneously initiate outbound connections from the LAN and over the VPN. IOW, exclude those IPs from the VPN. The GUI has a field called Policy Based Routing for this purpose. Once you add an IP or group of IPs to that field, the VPN is no longer the default gateway, and only those IPs listed in the policy based routing field will use the VPN.

Now sometimes ppl don’t like this limitation. They want *some* of the traffic for a local IP to use the WAN, and other traffic to use the VPN. And while it can be done, it gets a LOT more complicated, because now you need to qualify your routing based not just on IP, but also ports (or other criteria). And that means scripting your own policy based routing to replace that of the GUI. And that process requires that you create an alternate routing table, mark packets in the mangle table that meet that criteria, and add ip rules that tell the routing system to use that alternate routing table whenever it sees those marked packets.

That’s why this isn’t going to be corrected w/ a simple firewall rule or two. The only thing that determines how something is going to be routed is the routing system, specifically the routing tables. The only thing we can do w/ the firewall is mangle packets in such a way that the routing system treats them differently, namely, send some packets to the main routing table w/ one default gateway, and other packets to a second/alternate routing table w/ a different default gateway.

I have a example script for this purpose on PasteBin. It’s rather elaborate because it’s intended to serve a wide variety of purposes, but it illustrates the fundamental principles I’ve just described.

http://pastebin.com/f4rkPpu3

I have seen similar but far more stripped down versions of this type of script on the ‘net, often from VPN providers who are trying to solve this same problem for their customers. If I can find one of them, I’ll post back.

This is why I strongly encourage ppl to just not create a situation where you need both remote access and the initiation of outbound connections from the same local IP. It just makes things whole lot easier. But if you insist on it, you’ll need to code up your own policy based routing, similar to what I’ve done in that script.

P.S. Another way to force the use of the WAN for replies from remote access is by adding a specific route via the WAN to the public source IP of that remote access in the main routing table. That works because the routing system always prefers more specific routing instructions over more generalized ones, with the default gateway being the MOST generalized. Problem is, most times you don’t know the public IP from which you’ll be doing your remote access, making this more theoretical than practical. But if you’re lucky enough to have this situation (e.g., you always did your remote access from work w/ a well-known public IP), it would work.


I don't mean to hijack this thread, but I have wasted my life away with 20+ hours of trying to figure out port forwarding through a VPN from a forwarded port on the VPN provider side. Would it be possible for you @Ebigrad to take a look at this very similar problem and see if you can help me come up with a solution? https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1147506#1147506

_________________
Nerd-Tech - Exploring Technology, Computers, and Techno…

Been Hackintoshing since 2016...
https://github.com/danrancan
dan@nerd-tech.net
My Blog https://nerd-tech.net
Join me on key base! and Add me on Keybase

Linksys WRT3200acm Firmware v3.0-r41380 std (10/24/19).
Goto page Previous  1, 2 Display posts from previous:    Page 2 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum