Two steps
a. ensure vlan when created has interface of bridge
b. ensure port 7 is identified as a bridge port.
I am assuming this port goes to the USER(S) of Proton.
If its to a managed switch then trunk port
If its to a single device then access port
and apply on /interface bridge ports and /interface bridge vlans as required.
Yep. That's what I needed to do. I put ether7 back as a bridge port and make the proper settings for the VLAN and all.
It is now working! Yay!
Thanks for all the help!!!
Great news!
okay but need to know, do both work or just one option work.......
I am curious as to the op trying both options to see which works
/ip address
add address=10.2.0.2/24 (or /30) interface=ProtonVPN network=10.2.0.0
OR
/ip address
add address=10.2.0.2/32 interface=ProtonVPN network=10.2.0.1
I can try other addresses later, but I don't think it will matter as ProtonVPN does not know what I have set up on the system....
@mkx has already explained and gave examples about /32 addresses under /ip address. Let me add my way of trying to "understand" this:
Whenever you add (or something else like DHCP or PPPoE client dynamically adds) an entry under /ip address by associating an address a.b.c.d/m and network address x.y.z.w to an interface intf, it effectively does the followings:
a.b.c.d on the interface intf./m part and appends it to the network address x.y.z.w to create a destination subnet x.y.z.w/m, and use this to dynamically add a connected route (a route with flag D and C) with destination x.y.z.w/m gateway intf.When m=32, there is no requirement that a.b.c.d and x.y.z.w have to have anything in common at all. Only for shorter prefix length (m < 32) does RouterOS automatically calculate and enforce the network address.
For point-to-point-like interfaces you can have fully unrelated addresses on the two ends of the link. Here is an example of my PPPoE client connection with IP addresses from my ISP (FPT) where the Address and Network fields are totally unrelated:
This dynamically produces this route:
Here you can see the /32 prefix length and the 113.xxx.xxx.xx3 network address have been taken and used as the route's destination. And the local address of the router on the pppoe-out1 interface is the 42.xxx.xxx.xx4 address.
So now when a packet is destined for 113.xxx.xxx.xx3, this route will be used (because /32 is probably the longest matching prefix length), and pppoe-out1 will be used as outgoing interface. If the packet originated from the router, 42.xxx.xxx.xx4 will be used as source. If not (packet is forwarded) and we have SRCNAT masquerade applied, then the 42.xxx.xxx.xx4 will be used to rewrite the source address.
When you normally setup your LAN/VLAN interface by adding a /24 entry to /ip address, such as this:
The exact same thing happens. The 192.168.1.0/24 route is constructed as above, and packet sent to addresses within that subnet are routed through the bridge interface. And the router use 192.168.1.1 as its address on bridge. The only difference is that when you use a prefix length smaller than /32 the router will automatically adjust the network address based on the value of the address field and the prefix length.
But if you only need to communicate with one single device over an interface, even if that's an ethernet interface (not PPPoE), you can of course only add an /32 address to the interface under /ip address. Because you only need to talk to 1 remote host, a /32 route to that exact address is enough. And that route will be created if you specify that remote host as network address and chose /m to be /32.
Here is an example on my router, that has a SFP GPON stick. That stick has a management interface at the address 192.168.2.10, and on my router the interface is vlan1000 (an ethernet interface). I can add an address entry so that vlan1000 has the whole 192.168.2.0/24 subnet, but I don't have to, and don't want to, because there's only that GPON admin interface I want to talk to. So I add the address entry on vlan1000 like this:
So when I enter http://192.168.2.10/ in my web browser, the router knows that it has to look for 192.168.2.10 on the vlan1000 interface, and because that interface is in the WAN list, masquerade is applied and the GPON device see incoming packets with the router's address 192.168.2.2. If I try to connect to 192.168.2.8 or 192.168.2.1 or 192.168.2.100 then the router won't try to use this vlan1000 interface, but will use my default 0.0.0.0/0 WAN route instead.
Back to the OP's configuration: In his WireGuard config, he only needs one single remote peer (of ProtonVPN), whenever he uses this peer (to talk to it or to use it as gateway), his router only needs to address one single IP address of that peer, which is 10.2.0.1.
To know that the ProtonVPN interface must be used as outgoing interface to reach 10.2.0.1 only one route with destination 10.2.0.1/32 gateway ProtonVPN is needed in the route table (no need for 10.2.0.0/24 or 10.2.0.0/30 or whatever. And the side of the router on the ProtonVPN WireGuard link should have the address 10.2.0.2. Which mean this is a perfect reason to add the IP address entry as:
/ip address
add address=10.2.0.2/32 interface=ProtonVPN network=10.2.0.1
@NA9D please note that the network address is 10.2.0.1 and NOT 10.2.0.2 like in your screenshot!
I don't think you are correct. In a 32 bit network there is only ONE address in this case 10.2.0.2. There is not separate network address.
Images from: https://www.calculator.net/ip-subnet-calculator.html
To have 10.2.0.1 be the network address is actually not possible. Because in a 31 bit network, you have two Ips - 10.2.0.2 and 10.2.0.3 and .3 is the broadest address. 10.2.0.2 is still the network address:
If you make it a 30 bit network, your network address becomes 10.2.0.0:
No, as I explained in the post above:
When you add the entry like this:
/ip address
add address=10.2.0.2/32 interface=ProtonVPN network=10.2.0.1
The router has the IP address 10.2.0.2 on the ProtonVPN interface and it creates a route entry in main routing table with dst-address=10.2.0.1/32 (notice where this 10.2.0.1 and /32 comes from) with gateway=ProtonVPN. This is what you want. Because when you ping 10.2.0.1 you want the router to use the ProtonVPN interface as gateway (outgoing interface).
If you instead wrote this:
/ip address
add address=10.2.0.2/32 interface=ProtonVPN network=10.2.0.2
The added route has destination 10.2.0.2/32 which is a useless route. You can see this route right now in the IP -> Routes table if you configured the router like that.
Because the router has the 10.2.0.2 address already and doesn't need to know how to reach 10.2.0.2. In fact, it will use the lo interface (the loopback interface) when talking to 10.2.0.2 (itself) and not ProtonVPN so this route entry is nonsense.
And now the router doesn't have a specific route to 10.2.0.1 at all (again, look in your current route table). If you ping 10.2.0.1 right now it might try to use the default 0.0.0.0/0 route.
Again, this is not "a 32 bit network". It's a point-to-point link with two unique, single ends. There is no broadcast address and no network address.
Okay so pt to pt, is different and I have been thinking of it as a standard ethernet type setup.
Okay
So 10.2.0.2/32 network=10.2.0.1 works
What about
10.2.0.2/24 network=10.2.0.0 does it work but its to WIDE???
Yes, this will of course work too, because when you added the /ip address entry like that:
10.2.0.2 on interface ProtonVPN (same as the alternative way)dst-address=10.2.0.0/24 gateway=ProtonVPN (instead of dst-address=10.2.0.1/32 gateway=ProtonVPN of the other way above).If you want to talk to 10.2.0.1, there is no difference, both routes can be used to find out that ProntonVPN is the interface to be used as outgoing interface.
The difference is when you try to talk to another address like 10.2.0.15:
ProtonVPN interface as outgoing interface (because the route says it can route to any addresses within 10.2.0.0/24). But whether the other side really accepts this packet is another story. We don't know if ProtonVPN will drop the packet or if they are careless and the packet is sent to another customer (very unlikely, so probably not)./32 address the route is only responsible for the destination 10.2.0.1/32, so packets sent to 10.2.0.15 will not leave the router via the ProtonVPN interface. Probably the only matching route is the 0.0.0.0/0 default route, so the router will try to send it through the main WAN interface, and this of course will be dropped by the ISP if they are not incompetent.Which will never be the case for a user given a single IP address to go out internet.
It is not correct (accurate) but it works, and that was my concern, not being IT & networking savvy I wanted to make sure my advice although not perfect works in all cases for wireguard...
OK. Now, I have a new question related to this.
I want to create a firewall rule to send all traffic from a specific LAN IP address to the ProtonVPN.
This morning I created a NAT rule as shown below:
It seemed to be working fine and doing what it should. And then it stopped working. I've tried to add a firewall rule of the same.
Still not working. Not sure why it was working and now it isn't. I want to send all traffic from 192.168.0.1 (or any specific LAN IP) to the ProtonVPN connection and prevent it from going over the normal WAN connection.
Where am I going wrong?
It's not done with NAT rules like that. You can remove that rule that you've added.
Assuming that you've followed @anav guide on this post regarding:
Adding a routing table named useProton with fib turned on.
Adding the default route in the useProton table with gateway ProtonVPN.
Adding the routing rules, especially this rule should be at the top of the Routing rule table:
/routing rules
add min-prefix=0 action=lookup-only-in-table table=main
Then your new requirement of:
can be achieved by having this additional routing rules at the end of the Routing -> Rules table:
/routing rules
add action=lookup-only-in-table src-address=192.168.0.1 table=useProton
That is manageable if you only have a few individual IP addresses or subnets to include into the exception (one routing rule per address or subnet). If you have many more addresses/subnets, or if you more complex conditions, then using mangle rules with mark-connection and mark-routing would be better.
OK. Thanks.
Yes. Followed all of it.
Perfect. Thank you. I will try that. Right now, it's just one IP but I may use more - TBD but still only a handful at most.
It is confusing knowing when to use Routing Rules vs. Firewall Rules.
Not at all.
The reason we dont use routing rules all the time is that they cannot be applied to some users in a subnet or users from different subnets if the numbers are to great. In other words one can efficiently use firewall address lists to identify users but those lists are not useable in routing rules, they are perfectly fine to use in mangle rules however.
For a whole subnet or a few users, routing rules are manageable, but if its other than that mangles are more practical.
I cannot nor will comment without seeing facts, which means the latest config.
/export file=anynameyouwish (minus router serial number, any public WANIP information, keys )
It all seems to be working now.
But what is strange is that initially with the NAT rule I posted above, it WAS working. But I guess I was trying to do some stuff that ProtonVPN does not allow in the free version so the connection dropped. That's when the MikroTik started to "ignore" the NAT rule and processed the traffic as if the rule didn't exist. Should it do that?
And would it do it now with the routing rules put in place?
In addition to what @anav wrote about address list (including dynamic address lists that can be populated with static DNS entries or action=add-dst-to-address-list / action=add-src-to-address-list rules, which routing rules cannot use at all):
With mangle rules you can modify the routing based on many more conditions, such as: ports, protocol (and other information in the packet header), MAC address (especially useful with IPv6 and clients with dynamic SLAAC addresses), packet size, bridge port, time schedule, as well as information about previous packets of the connection (packets that arrived from the other direction) that you can get from connection-state or connection-mark.
While the advantage of routing rules is that they are very simple and performant (compatible with FastTrack).