Thanks ET
Yes, forwarding all wgin (port) packets to the WG server. This port is
for the -in- channel only, and once the tunnel is set up stateful
traffic can pass back and forth.
I've found the problem. The DNAT rule in the router was not enough. I
also needed an ACCEPT rule of the wgin ports _coming in_ to the router:
ACCEPT net $FW udp wgin -
Was this my mistake? The DNAT docs specifically say that if you use
DNAT- it will only set up the route and not the associated ALLOW
directives, so my DNAT rule should have ALLOWed the packets by itself.
But it didn't. As a fallback I was hoping for another firewall that's
maybe GUI and easier to set up yet just as flexible.
In any case it's working now.
On the WG server I have this inWG interface for inbound traffic from
remote devices like phones. laptops, etc. I also have an outWG channel
which by default carries all LAN internet traffic out my WG VPN service.
(AzireNet) When you have two channels like this in the same server,
a/nother little-known rule/ is in the WG config files, you must have
FwMark = {random#<65525}
... in the [Interface] section of both channels' .conf files. The
number must be the same for both channels. I have no idea what this does.
On 3/19/19 12:09 PM, Erich Titl wrote:
> Hi
>
> Am 18.03.2019 um 06:28 schrieb C. Cook:
>> 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
>> -
> OK this just shows there is _no_ traffic on this interface to or from
> this port. I was under the impression that wireguard was bidirectional,
> so I am wondering about the eth0 vs. eth1 interfaces.
>
>>
>> My router rule is:
>>
>> DNAT net local:10.2.1.1 udp wgin
> I have no clue why you would want to route all udp traffic to your local
> net, maybe to your wireguard server? But then how do you masq the
> outgoing traffic, because by doing so this is moot.
>
> -
>> ... 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.
> Well if you are afraid, that means there are holes :-) Post at least
> something people can have a look at and do not need to trust your
> description.
>
>> Alternatively can someone recommend another firewall?
>>
> What difference would that make, you would make the same mistakes there.
>
> I would try to see if I can follow the packet flow. Are you sure your
> wireguard server connects to the opposite wireguard instance? Then you
> would need to see the packet flow from your client machine(s) through
> your wireguard server to the opposite siede and have a look if the
> replies take the same route.
>
> cheers
>
> ET
>
>
>
> _______________________________________________
> 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
