Can anyone recommend a solution? Tracing this out I find that Shorewall is not actually port-forwarding my WireGuard-in port.
# tcpdump -i eth0 port wgin tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:52:33.881605 IP 172.52.40.200.28936 > 50-135-95-5.hllk.wa.frontiernet.net.wgin: UDP, length 148 10:52:38.814108 IP 172.52.40.200.28936 > 50-135-95-5.hllk.wa.frontiernet.net.wgin: UDP, length 148 # tcpdump -i eth1 port wgin tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes - My router rule is: DNAT net local:10.2.1.1 udp wgin - ... and that is accurate. But Shorewall is simply and absolutely not passing along the packets. I've rebooted the router and no change. I have never seen it before where port-forwarding does not work. I'd rather not post my shorewall dump here for the permanent record. Alternatively can someone recommend another firewall? On 3/17/19 1:02 PM, C. Cook wrote: > On 3/17/19 11:05 AM, C. Cook wrote: >> >> I've studied the docs and am thoroughly confused about whether to use >> arprules, mangle, policy, providers, proxyarp, routes, rtrules, snat, >> or tunnels, or some combination. I sure hope someone can advise. >> >> I have a Wireguard server with three interfaces: >> - inWG - remote devices (phones, laptops) come in here, to reach the LAN. >> - outWG - The LAN (and in some cases remote devices above), goes out >> here over a VPN hoster, ultimately to the internet. >> - eth0 - The local LAN interface >> >> As things are now, the local LAN can communicate just fine, through >> eth0 to outWG, with a masquerade rule in snat. >> >> BUT remote devices coming in to inWG are getting sent right back out >> outWG, no matter the destination IP, rather than going to the local LAN. >> >> What I need is for remote devices with a destination of 10.1.1.0/24 >> to be routed from inWG to eth0 (or to localhost if 10.1.1.1). And if >> remote devices are calling for an IP outside 10.1.1.0/24, those >> packets should be routed from inWG to outWG. >> >> If I'm understanding, if I snat inWG to eth0, it would not allow >> access to 10.1.1.1, nor for unknown IPs out outWG. This implies that >> maybe some prerouting needs to take place, and there are so many >> possibilities I'm swamped. >> >> Another possibility is in my masquerade rule, if there's some way to >> NOT 10.1.1.0/24. >> >> Can anyone advise? >> > This doesn't work, in snat to dump out before the masquerade rule: > > CONTINUE 10.2.3.0/24 eth0:50.135.95.5 > > SNAT doesn't work either. > > # tcpdump -i inWG 'icmp[icmptype] = icmp-echo' > > ... on the WG server shows nothing coming in, while pinging from the > phone. > > The WireGuard logfile shows this: > > 03-17 12:44:50.741 20823 30703 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Starting... > 03-17 12:44:50.741 20823 29800 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Routine: nonce worker - started > 03-17 12:44:50.741 20823 29800 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Routine: sequential sender - started > 03-17 12:44:50.741 20823 29800 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Routine: sequential receiver - started > 03-17 12:44:50.741 20823 30703 I WireGuard/GoBackend/mercury: Device > started > 03-17 12:44:52.092 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Sending handshake initiation > 03-17 12:44:52.098 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Awaiting keypair > 03-17 12:44:57.123 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Handshake did not complete after 5 seconds, > retrying (try 2) > 03-17 12:44:57.123 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Sending handshake initiation > 03-17 12:45:02.178 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Handshake did not complete after 5 seconds, > retrying (try 2) > 03-17 12:45:02.178 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Sending handshake initiation > 03-17 12:45:06.921 20823 20823 I menu_item_selected: [0,Settings] > 03-17 12:45:06.932 20823 20823 I am_on_paused_called: > [0,com.wireguard.android.activity.MainActivity,performPause] > 03-17 12:45:06.952 20823 20823 W ActivityThread: > handleWindowVisibility: no activity for token > android.os.BinderProxy@dd2ec4 > 03-17 12:45:06.958 20823 20823 I am_on_create_called: > [0,com.wireguard.android.activity.SettingsActivity,performCreate] > 03-17 12:45:06.974 20823 20823 I am_on_start_called: > [0,com.wireguard.android.activity.SettingsActivity,handleStartActivity] > 03-17 12:45:06.976 20823 20823 I am_on_resume_called: > [0,com.wireguard.android.activity.SettingsActivity,RESUME_ACTIVITY] > 03-17 12:45:07.262 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Handshake did not complete after 5 seconds, > retrying (try 2) > 03-17 12:45:07.262 20823 23013 D WireGuard/GoBackend/mercury: > peer(VdwH�^��S92k) - Sending handshake initiation > 03-17 12:45:07.504 20823 20823 I am_on_stop_called: > [0,com.wireguard.android.activity.MainActivity,STOP_ACTIVITY_ITEM] > > It has never been able to complete the handshake, and there are > absolutely no Shorewall block errors in dmesg when I try to connect. > I've gone over WG configs many times. Those in the WG IRC channel > call my construct "convoluted", and dismiss it because an enterprise > use-case is clearly beyond them. > > OpenVPN, tinc, etc have exactly the same problem. And I don't have > time to get a Master's degree in IPSec. > > I was really hoping to have not just outgoing VPN, but also incoming. > But at this point, with Tom gone, it looks like this is not going to > be possible. I have spent weeks on this problem full-time, and can't > afford to spend any more. > > > > > > > > > > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
