Strange WireGuard Site-to-Site Behaviour

[opn00b]

Hi,

I recently setup a Site-to-Site VPN using WireGuard with the following configuration:

Site A --> Main Site
Site B --> Remote Site

Site A
Main Network: 192.168.1.0/24
Tunnel Address: 10.0.10.1/24

Site B
Main Network: 192.168.4.0/24
Tunnel Address: 10.0.10.4/24

Site A Endpoint
Name: Site B
Allowed IPs: 10.0.10.4/32, 192.168.4.0/24 --> these are Site B's IPs

Site B Endpoint
Name: Site A
Allowed IPs: 10.0.10.1/32, 192.168.1.0/24 --> these are Site A's IPs
Endpoint Address + Port: [Site A's External IP Address] + [Port]

I also have created a WireGuard Interface at each site that is bound to the wg0 device.

Firewall

At each site, I have an allow all on the WireGuard interface, to provide WG Net with access to the whole network.

I also have a firewall rule on WAN to allow the WireGuard port (51820) at both sites.

Current Status

The VPN is connected, and both sites can ping each other + access various services that are hosted on servers on the other site. For example, Site A, can connect to servers at Site B + Site B can connect to servers at Site A.

Here's where the strange behaviour starts. For one particular IP address that I tested (located at Site A): 192.168.1.220, Site B can access a service at port 9000, but not different services using other ports. There's a different service at port 7878 and 7879... but it is not able to reach those via web browser (or curl). I have tried running those same services (7878 and 7879) on different ports, but it still doesn't work.

To do this testing at Site B, I am using a regular computer on the LAN (it's IP is 192.168.4.157). For clarity, when navigating from this computer:

192.168.1.220:9000 --> works
192.168.1.220:7878 --> doesn't work
192.168.1.220:7879 --> doesn't work

The thing is, when accessing those services via curl on the actual router itself (Opnsense CLI using curl) at Site B, all services load (even the 7878 and 7879 services).

One last thing to note, is that prior to creating a WireGuard interface at Site B, the firewall was blocking the 7878 and 7879 services (for some reason - "Default deny rule"), but the 9000 service always worked. After creating the WireGuard interface at Site B, the firewall allows the traffic (in all cases), but nothing gets through for 7879 and 7979 (on the test PC, but still works on the router itself). I don't see any blocked messages in Live View.

Any assistance would be greatly appreciated.

[mimugmail]

Screenshot of Firewall rules please

[opn00b]

Site A

https://imgur.com/a/hbwAi0A

Site B

https://imgur.com/a/1m41RmW

[mimugmail]

Why did you assign the wg interface?

[opn00b]

I'm not entirely sure to be honest. Without the interface, the firewall logs show denied when using port 7879, but allowed when using port 9000 - see screenshots below (taken from Site B's firewall logs):

https://imgur.com/a/Kzyq78I

With the interface, I don't see any denied entries in the log.

[mimugmail]

So you need to allow the reply packet on Site B? Can you allow everything on wg assigned rule tab?

[opn00b]

I have added a new rule on Site B to allow all for "out" (as well as "in"). See screenshot here: https://imgur.com/a/UjNlEZ3.

Unfortunately, still receiving the Default deny rule in the Live View.

[mimugmail]

Are you have some port foward rules for transparent proxy or similar?

[opn00b]

Not sure I entirely understand the question.

When accessing the service directly from Site B - by going from a computer at 192.168.4.167, in the web browser, and entering 192.168.1.220:7879, it doesn't work (receive those "deny" messages in the firewall). Accessing the same IP (192.168.1.220) using the same computer at Site B using a different port (9000) works.

[opn00b]

Just wanted to know if you had any more ideas? I can't seem to get this working.

[opn00b]

Gentle bump

[Maurice]

Had a quick look at your screenshots. The NAT rules don't make sense to me at all:

- Why is the WireGuard port forwarded from the WAN address to the LAN address?
- Why are there outbound NAT rules for the WireGuard net?

Not sure if this is the root cause, but would fix that first.

Cheers

Maurice

[opn00b]

Thanks for your response.

To be honest, I'm not sure if I can answer those questions since I just followed some various tutorials. As for the outbound NAT rule, I believe I initially had to create it so that my remote devices could access the internet.

I have removed both the port forwarding rules & the outbound NAT rule (I disabled them).

The good news is that the VPN still works (can ping and access various IPs), however the same issue persists (accessing service on port 9000 works, but 7879 doesn't). Firewall on Site B gives the same "Default Deny Rule" when accessing the service at 7879.

[micharambou]

Would you mind to check, if you can open a RAW TCP Connection between Server and client?

I believe the issue is somehow service related since the screenshot of site B's firewall log looks strange. Missing source and destination port on the initial TCP Reply probably makes the firewall to drop the connection.

Server

Code: [Select]

michael@manjaro-xps13 ~ % netcat -l -p 7879 -vvv
Listening on any address 7879
Connection from 10.23.45.2:48756
Test. This works
Total received bytes: 17
Total sent bytes: 0

Client

Code: [Select]

$ netcat 192.168.100.24 7879 -v
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.100.24:7879.                                                         
Test. This works
Make sure to temporarily disable the affected service on the given listening port to make sure the tcp port can be bound.   

[opn00b]

Thanks for your response. I have tried using netcat as you suggested - please see below:

Server

Code: [Select]

netcat -l -p 7879 -vvv
Listening on [0.0.0.0] (family 0, port 7879)
Connection from 192.168.4.10 54822 received!
Test. This Works
Client

Code: [Select]

netcat 192.168.1.220 7879 -v
192.168.1.220: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.1.220] 7879 (?) open
Test. This Works