So the problem seems to be "selective" or intermittent. However, I noticed that from the same source and to different destination IP's through the tunnel, some are working and some are not! Here's proof of that:
#NEWSHOSTING VPN SETUP OF PFSENSE TORRENT#
That public IP is an external IP from a torrent peer.
With the NAT rule in place, yes I do see the source getting translated to the local WG interface IP and leaves the WAN and shows in the remote WG interface.
If you remove the /32 NAT rule and capture packets on the WG interface - do you see what I captured on my tcpdump (the source getting translated to the tunnel IP) or you don't even see that ?įor me the NAT rule seemed to work, just that the packets don't leave the WAN for some reason.ĭid you mean when keeping the /32 outbound NAT rule? I'll put some more effort on it tomorrow. This also proves that both pfsense boxes exhibit the do you have any said in Policy-based Routing (outbound) and port forwarding (inbound) through WG That doesn't work for me. The routing for both PBR and port forwarding is basically the same but only reverse of each other. So from my observations above, I can conclude that, for some odd reason, both PBR and port forwarding work with the "first" source IP and they don't with succeeding source IP's, if that even makes sense. Site B's WG0 interface never sees these packets. The same exact behavior happens like the PBR issue above and that is the inbound packets reaches Site A's WG0 interface but stops there.
The monitoring itself is already the keep alive. If the IP you set in the Peer WG Address field is included in the IP subnet settings of the actual WG interface, a gateway is automatically created and gateway monitoring is enabled by default. I do not have keep alive on both sides enabled and it works just fine because of two things:Ī. It works both ways because /32 is basically a single IP address also but it just makes it more simple if you use a single IP and this is what's documented in the official pfsense WG S2S article anyway. In the Peer WG Address field of each side's peer settings, I make sure to specify a single IP address without the CIDR (/32) notation. I have the same settings except for a few things: I have the exact same setup as his because one side is behind a CGNAT and the other side has a static public IP. I have everything stable with WG except for said in Policy-based Routing through WG Tom over at Lawrence Systems just put out a YouTube video for Wireguard site to site. I'll check your thread and maybe I can help. I have a PBR rule but I can't even get the tunnel stable enough to test the rule. Coming from OpenVPN, then IPsec, and now WireGuard, I can say that WireGuard is very straightforward to setup so the chance of messing something up is said in Policy-based Routing through WG I have another thread on here about my problems with WG on PF. Thanks but I already read all the official documentation while I was setting this up. But I thought I'd pass this along in case you haven't seen it. Said in Policy-based Routing through WG I haven't set up a site-to-site Wiregurad tunnel yet so I'm not going to be much help.
0 kommentar(er)
