Just for clarity, this is the output of the traceroute 8.8.8.8 command when executed on the site B router:
Hello,
There is quite a lot of information in this thread, sorry if I got something mixed up. Went over the configuration once again, this time with an OpenWRT device:
-
OpenWRT
WireGuard instance configuration:
WireGuard Peer configuration:
Firewall configuration:
-
RUTX50
WireGuard instance configuration:
WireGuard peer configuration:
I think the issue previously was within the firewall of the OpenWRT router, as the WireGuard zone needs to be able to forward traffic to WAN as well, not only LAN. That’s why you were losing connection to the OpenWRT router.
Best regards,
I understand. The thread became a bit of a mess, because the forum wouldn’t allow me to have more than one picture per post initially. I think it’s fixed now. 
I will verify your suggestions later tonight.
In case I can’t get it to work, I could arrange a temporary remote access to the RUTXR1 (site A) for you. I feel more like an obstacle now, than helpful. Perhaps if you had direct access, you could notice issues that slip past me due to inexperience. 
Please PM me in such case.
I’m 95% sure it will work, but in case it does not, you’ll need to contact your reseller, or our sales manager by filling out the Contact Us form here to establish a private communication channel.
Let me know how it goes!
Best regards,
I was about to implement the changes you described about the site B firewall settings, but before I do that, I would like to understand why? Don’t get me wrong, I’m not trying to be obstruent, but I’m a bit reluctant to make the change for the following reason:
- the B site is very far away. And it’s critical that I don’t loose contact with it, because if I can’t access the home automation system over there, I will get in a lot of trouble. So changes that could result in “cutting off the tree branch you’re sitting on” makes me very anxious. I have no means of reversing any configuration change other than getting on a train for six hours, and then bus for another hour. Not to mention the cost.
- Site B has been working with it’s current configuration for several years. The thing that changed is at site A, where the WG tunnel is now terminating in the edge router, instead of client inside the A network. This makes me wonder about why I need to change how the WG firewall zone forwarding is done on site B?
To my understanding, as long as the WG tunnel comes up correctly (which it does), I shouldn’t have to change anything in the config of site B. Or have I totally misunderstood what WG is? I’ve been under the impression that it is an interface like any other interface, wan for instance.
In case it was lost among the many posts I have made in this thread, let me repeat that it is outmost important that no B site client traffic may leak outside the WG tunnel. And that also goes for traffic coming via the tunnel from site A. The wan interface on the B site router may only be used for a) the encrypted WG tunnel traffic, b) DNS requests by WG to resolve the site A address, and c) NTP to set the B router’s clock. But that’s it. No device on the B (or A) lan may ever utilize the B wan directly.
This requirement comes from a liability perspective. I am borrowing/renting internet capacity from a neighbour at site B, which is illustrated by site C in my network diagram in post 14. The agreement for this internet access was that the neighbour should be able to claim total deniability for the traffic generated by me, transiting to his ISP.
I know, this isn’t your average bread-n-butter setup, but it was the only way for me to get some sort of broadband connectivity without paying a fortune to have a fibre cable laid out only for me. (Instead I have a km-long radiolink across a lake to my neighbour )
I also found this thread from OpenWRT that kinda supports my theory of how WG works: Understanding the 'Route Allowed IPs' option in Wireguard - Network and Wireless Configuration - OpenWrt Forum but then again, I have a limited understanding of how ip traffic is actually routed at a low level.
Hello,
If this is the case, I’d suggest you get in contact with us via the Contact Us form, or your reseller. This way we’ll be able to organize a remote session so that I could review the changes live. Please link this thread when either filling out the form or contacting your sales manager, and I’ll get assigned to your ticket. At the moment, I cannot guarantee that the connection to the site will not be lost, thus I’d like to doublecheck everything myself before applying any changes.
As per your question, I’m not sure how the setup worked before, as from your screenshot, I can see that WireGuard can only forward traffic to LAN, from which it will not be able to exit to the internet. Adding the WAN formwarding will not break the setup, however, changing the Wireguard settings could, and this is the part I’d like to double check.
Best regards,
Thank you for still wanting to help, despite my odd setup. I realize I have a tall bill of requirements 
I will apply for a direct private communication channel, as you suggest. I have also thought about the possibility to add a cron job that would revert the B site settings to a saved backup with a known working state, unless being manually disabled. That way I could set this job to execute within a couple of minutes or hours from me beginning to try different settings, and in case connection is lost, the cron job would revert those changes. But if the changes work ok, then I could just cancel the cron. Does this sound doable?
Another thing about your comment on WG and routing: From the tests I have been doing on the B site router, it seems that OpenWRT differentiates its behaviour between the router itself, and traffic being routed through it. Which would explain why I can get things like ping and traceroute to work on the router itself (by exiting directly though the wan interface), whilst the same traffic coming in through the lan interface gets redirected to the WG interface. The WG instance seems to be implemented in such a way that it implicitly uses the wan i/f for its tunnel side (10.10.10.2). And being a virtual device on the router itself, it doesn’t have to adhere to the firewall rules, hence bypassing them directly to wan. This behaviour would be in line with the ping and traceroute executed from the routers CLI.
Perhaps I got this totally wrong, but this is my conclusion from the behaviour I can observe. 
Indeed, cronjob would work well here, just make sure the correct uci commands are used and changes are applied.
That’s right, the router itself is considered as Device (input) in the firewall rules, thus any traceroute tests should be performed from the LAN client. This is the same for both OpenWRT and RutOS.
Best regards,
This topic was automatically closed after 15 days. New replies are no longer allowed.