only one side of site-to-site VPN (wireguard) working

Started by sawdustdood, July 11, 2021, 02:40:42 AM

Previous topic - Next topic
I'm attempting to setup a WG site-to-site with Opnsense 21.1.8_1 on one side and a Linux iptables firewall (Freshtomato 2021.3) on the other.  Currently, I can go from my Opnsense LAN (let's call it 192.168.1.0/24) to the IPTables LAN (192.168.2.0/24) without any issue and reach any IP on the subnet.  The two tunnels are 10.0.0.1 and 10.0.0.2 respectively.
The problem is coming from the IPTables LAN to the Opnsense LAN (192.168.2.1 -> 192.168.1.1), I can see the incoming request logged from 10.0.0.2 to my 192.168.1.x as PASS, but am never able to actually establish a connection (curl, ssh, whatever - I don't see the incoming traffic from tcpdump on the destination host).  The wireguard itself handshakes find and keeps a stable connection.

On the Opnsense I have:
  - gateway defined for the wireguard interface (WG_int)
  - outbound NAT rule (src any / dst 192.168.2.0/24) before my WAN outbound NAT
  - LAN rule IN (dst 192.168.2.0/24 via WG_int)
  - WG_int rule IN (src WG_int net via WG_int)

On the IPTABLES:
  iptables -A INPUT -s 192.168.1.0/24 -i wg0 -j ACCEPT
  iptables -A INPUT -s 10.0.0.0/24 -i wg0 -j ACCEPT
  iptables -A FORWARD -i wg0 -j ACCEPT
  iptables -A FORWARD -o wg0 -j ACCEPT
  route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.2 dev wg0
  iptables -t nat -I  POSTROUTING 1 -d 192.168.1.0/24 -o wg0 -j MASQUERADE

I can't seem to grasp what I am missing that is preventing establishing a connection from my .2 subnet to my .1.  What am I missing?

Thanks,
Ted

What are the AllowedIPs on the Endpoint in OPNsense?

on Opnsense:

  allowed ips: 192.168.2.0/24, 10.0.0.0/24

on IPTables box:

  allowed ips: 192.168.1.0/24, 10.0.0.0/24

Hmm. Shouldn't the second entry on each be 10.0.0.2/32 and 10.0.0.1/32 respectively?

In fact, do you really need to NAT the traffic rather than just adding routes with IP forwarding enabled? Something like this? https://www.procustodibus.com/blog/2020/12/wireguard-site-to-site-config/

July 11, 2021, 03:00:43 PM #5 Last Edit: July 11, 2021, 03:46:50 PM by sawdustdood
You are correct on that front.  The NAT rules are unnecessary, simple routing (via the gateway tunnel) is sufficient.  Thanks for the suggestion, I'm not too sure why I went down that rabbit hole.  I have removed the NAT rules from both sides and am in the same place as before.  Working Opnsense -> IPTABLES but not the other way around.

For allowed ips in the wireguard config, the /24 netmask on 10.0.0.x should catch both .1 and .2 and is a bit lazy, but should do the trick. 

Still not too sure what's disallowing traffic to reach from the .2 to the .1 hosts, but can see it PASS on my WG_int rule in the firewall log.  Sooo close.

example of what I see in tcpdump on opnsense... from running "curl http://192.168.1.50" on 192.168.2.1:


# tcpdump dst port 80 -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes
06:41:29.741005 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126817852 ecr 0,nop,wscale 4], length 0
06:41:29.741020 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126817852 ecr 0,nop,wscale 4], length 0
06:41:32.778243 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126818153 ecr 0,nop,wscale 4], length 0
06:41:32.778252 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126818153 ecr 0,nop,wscale 4], length 0
06:41:38.742692 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126818754 ecr 0,nop,wscale 4], length 0
06:41:38.742699 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126818754 ecr 0,nop,wscale 4], length 0
06:41:50.764449 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126819956 ecr 0,nop,wscale 4], length 0
06:41:50.764454 IP 10.0.0.2.59257 > 192.168.1.50.http: Flags [S], seq 2904927047, win 5520, options [mss 1380,sackOK,TS val 126819956 ecr 0,nop,wscale 4], length 0


where this is what I'd expect going the other way - real sessions w/ acks and everything (not that I'm that great at reading tcpdump)..


06:44:41.529197 IP 192.168.1.50.40688 > 192.168.2.1.http: Flags [S], seq 189364071, win 65535, options [mss 1372,nop,wscale 6,sackOK,TS val 1195347397 ecr 0], length 0
06:44:41.546404 IP 192.168.1.50.40688 > 192.168.2.1.http: Flags [.], ack 1594281367, win 1029, options [nop,nop,TS val 1195347415 ecr 126837034], length 0
06:44:41.546541 IP 192.168.1.50.40688 > 192.168.2.1.http: Flags [P.], seq 0:76, ack 1, win 1029, options [nop,nop,TS val 1195347415 ecr 126837034], length 76: HTTP: GET / HTTP/1.1
06:44:41.572784 IP 192.168.1.50.40688 > 192.168.2.1.http: Flags [.], ack 432, win 1023, options [nop,nop,TS val 1195347441 ecr 126837036], length 0
06:44:41.572919 IP 192.168.1.50.40688 > 192.168.2.1.http: Flags [F.], seq 76, ack 432, win 1029, options [nop,nop,TS val 1195347441 ecr 126837036], length 0

Ugh... Finally fixed my problem..

needed to add a Floating Rule:

Pass any, IPv4 *, Source WG_int, Port *, Dest LAN net..

Thanks for the assist!