How to configure wireguard clients to connect to internal services

Installing and Using OpenWrt Network and Wireless Configuration
21

Sure, some of it may not. But the routing stuff should still all be compatible.

Yeah, but I'm not asking about syntax for 24.10.

Based on what's in the file fragments that I provided, though, is there anything that stands out from a routing configuration as obviously impeding the ability for a request to 1.2.3.4:443 from being sent to the WAN interface?

Ultimately, that's what I'm trying to achieve here. Surely anything that gl.inet changed in order to support their newer firmware wouldn't affect how the openwrt firewall module in 21.03 fundamentally worked. Again, I'm looking for a direction here. Something like NAT loopback (which works from the LAN to make this connection) that for some reason a second interface can't use, or isn't using. The client is connecting to the router's port 443 when resolving '1.2.3.4' rather than being sent from the 10.x.x.x interface on the router (the VPN's assigned address at the router) to 1.2.3.4:443. Why is that?

22

Also, to give you an idea about the differences, just hilighting one:

This would not work at all in the official openwrt. The wireguard config lives in the main network config file for the official project and doesn’t by default use any firewall marks. It also doesn’t support masquerading via the network config - that would be handled in the firewall config.

23

Tell you what — try it.

24

I don't have the gear set up to try it.

But OK, fine. You're determined to look for reasons not to help rather than reasons to give me a pointer in the right direction.

I appreciate your time, but really.....rather than try to find reasons not to help, I would have much more appreciated you finding ways in which you could point me in a productive direction that didn't involve ripping and replacing the firmware, followed by (likely) having to redo the entire configuration that I've put in place.

sigh

25

I’ll telling you, based on experience, that your current config (for the gl-inet vendor firmware) is too far removed from official openwrt to be meaningful for us to review. It is not a lack of willingness. You’re asking us to grammar check middle-English when all we speak is modern English.

We have given you two good options:

  • ask on the gl-inet forums and support channels — they are the ones who know how their firmware works
  • Install official openwrt and we can help you here.
26

If this were pure iptables, what would you have me look at? Forget that it's gl.inet. Forget that it's even some flavor of openwrt.

I have a router with three interfaces interfaces: PUBLIC, PRIVATE, and VPN.

Given this network and the diagram I posted at the outset, and assuming just iptables is all I'm using, what would I look at to get a system connected to the VPN interface to connect to a system behind the PRIVATE interface using the IP address assigned to the PUBLIC interface?

NAT loopback works from the private interface. It doesn't work from the VPN interface. Why?

That's it. That's the question.

27

Iptables documentation available on the internet. Current versions of OpenWrt use nftables.

I’m a bit confused as to why you believe that this forum should be both willing and able to resolve issues you are having with another vendor’s commercial firmware? Would you expect tp-link or linksys to help solve this issue?

28

Well, then we're both confused, because I'm confused as to why you won't just say "I don't know" if you don't know how to help. I guess when openWRT changed to nftables, you just purged all knowledge of how it's iptables implementation used to work from your memory.

And I'm confused why you decided to argue with me for (checks) 27 messages rather than just saying "I don't know" or leaving it so someone else who maybe did have some knowledge of an apparently ancient version of the code could come along and help.

I mean, I know that code that is 2 years old is pretty old code. It's not like I'm asking for help on a 3Com Netbuilder router here (a truly ancient piece of router hardware).

I'm using a router that uses firmware built on openWRT code. Yes, it's old. Yes, it probably has stuff added to it that isn't in the stock code. But the underlying routing code is openWRT's code.

So just forget it. Have a nice day. Sorry to have bothered y'all because I thought that just maybe someone here would be kind enough to give me a hand in figuring out why the heck this isn't working and what I'm overlooking.

29

Well, just in case anyone cares or runs across this topic trying to solve a simlar issue, I have resolved it. There may be a better way to do this, but this works.

  1. Add some custom firewall rules:
# DNAT from VPN clients accessing WAN IP on ports 80/443
iptables -t nat -A PREROUTING -i wgserver -d <external-address> -p tcp --dport 80 -j DNAT --to-destination <host>:<port1>
# (do this for each of the ports you need forwarded)

# Masquerade so responses go back through the router correctly
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d <host> -p tcp -m multiport --dports <port1>[...] -j MASQUERADE
# (Add each port in the first section to a comma-delimited list after the `--dports` switch.)
  1. Run the following on the router console:
uci set firewall.@include[-1].path='/etc/firewall.user'
uci set firewall.@include[-1].type='script'
uci set firewall.@include[-1].enabled='1'

I found this was necessary because while the firewall.user script runs when the firewall is started, on a restart or reload, it isn't. This ensures that the script runs whenever you change the firewall.

It may not be the most elegant solution, but it works.

1 Like