Yes.
It's correct.
root@OpenWrt:~# nft list chain inet fw4 forward_guest
table inet fw4 {
chain forward_guest {
jump accept_to_wan comment "!fw4: Accept guest to wan forwarding"
jump reject_to_guest
}
}
Yes.
It's correct.
root@OpenWrt:~# nft list chain inet fw4 forward_guest
table inet fw4 {
chain forward_guest {
jump accept_to_wan comment "!fw4: Accept guest to wan forwarding"
jump reject_to_guest
}
}
If I ping 1.1.1.1 I obtain this:
massimo@MacBook-Air-di-Massimo ~ % ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2
ping: sendto: No route to host
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: No route to host
Request timeout for icmp_seq 5
ping: sendto: No route to host
Request timeout for icmp_seq 6
ping: sendto: No route to host
Request timeout for icmp_seq 7
ping: sendto: No route to host
Request timeout for icmp_seq 8
ping: sendto: No route to host
Request timeout for icmp_seq 9
ping: sendto: No route to host
Request timeout for icmp_seq 10
^C
--- 1.1.1.1 ping statistics ---
12 packets transmitted, 0 packets received, 100.0% packet loss
massimo@MacBook-Air-di-Massimo ~ %
With VPN it works correctly.
you have a routing problem: two interfaces, wan and vpn are providing egress route.
by default wan is supposed to be "the" default gateway for your networks to access internet. all zones which are supposed to access internet should set zone forwarding to wan enabled.
but you have vpn zone (and respectively vpn interface) which also acts as default gateway.
run ip route to verify which is your default gateway. guest (or any other) zone will use this as default if firewall zone forwarding is configured. see mine as example:
$ ip route
default via 10.0.0.1 dev pppoe-wan
10.0.0.1 dev pppoe-wan scope link src x.x.x.x
192.168.1.0/24 dev br-lan scope link src 192.168.1.1
my default route is via device called pppoe-wan which has the ip address of 10.0.0.1. so any destination is not defined otherwise, i.e. which is not in 192.168.1.0/24 network, will be sent to 10.0.0.1 (unless firewall prohibits).
if you want selective routing then you must use pbr. that's a whole different story, but we can conclude that all your config in general works as should in spite you expect differently.
This is the result:
root@OpenWrt:~# ip route
default dev wg0 scope link
10.14.0.0/16 dev wg0 scope link src 10.14.0.2
146.70.182.59 via 192.168.192.1 dev wan
192.168.1.0/24 dev br-lan scope link src 192.168.1.1
192.168.3.0/24 dev wl0-ap0 scope link src 192.168.3.1
192.168.192.0/24 dev wan scope link src 192.168.192.173
But isn't it possible to create 2 networks and then assign the VPN to only one of these 2 networks?
that's the part which requires pbr.
I understand what I have to do.
Now I'll open another thread for help.
Thank you.
Disagreed.
@ilcobrapizzica please see here for a solution for two networks, only one of which goes through a VPN interface, that’s as simple as the guest network split and does not require policy based routing:
you are mixing selective DNS with selective routing as i see. in your thread too was suggested to use pbr for selective routing. if only selective DNS is the goal (as you stated in your thread "This is about avoiding DNS leaks ") then yes, you can set preferred DNS server per network.
anyway, am equally happy if OP follows your suggestion, or pbr route (as this is not my magnificent idea). which ever satisfies the requirements and feels more comfortable.
With all due respect, you’re incorrect in your assessment of my suggested setup. Routing is handled via disabling the default route (to WAN) in the guest/VPN network, and only forwarding traffic from it to the VPN zone. This is provably enough for separate routing, what I was asking for was whether this also stops DNS leaks, which, to my understanding, it should.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.