I'm planning on running multiple PPPoE connections from a RB to the same provider.
I wondering does router os support putting PPPoE client interfaces into a VRF?
Thanks in advance
Mark
Re: PPPoE & VRF
Since the client creates an interface, you should be able to add that interface to a VRF.
Mikrotik doesn't support automatically adding pppoe clients to a vrf when the Mikrotik is the PPPoE server, though.
Mikrotik doesn't support automatically adding pppoe clients to a vrf when the Mikrotik is the PPPoE server, though.
Re: PPPoE & VRF
Yepp, were still waiting for a mikrotik radius-attribute like 'mikrotik-user-vrf' ...
Till santa puts that under the tree, we can try with these humble scripts I've tweaked.
Made these with open-vpn, but it should also work with other ppp-based stuff
To get it work you will need a couple helper files and config-snippets in your box.
The VRF and the static-interface/s you try to dial to, must be preconfigured.
The scripts grab a radius-realm from the username. So radius-realmname=vrf-name ...
"fury@ponnyhof" will dial to vrf 'ponnyhof'
"fury@mezgerei" will dial to vrf 'mezgerei'
### it is presumed that fury has access-rights to both realms on your radiusd ###
ppp-up
...
ppp-down
...
Guess a global scheduled cleanup-script would also be usefull, to eleminate abandoned interfaces from failed log-on's and log-off's and 'poisoned' 'lock-file' content.
I'm not really the son of scripting-man ... so enhancements, opinions and testresults are highly appretiated.
######
some log-stuff:
Till santa puts that under the tree, we can try with these humble scripts I've tweaked.
Made these with open-vpn, but it should also work with other ppp-based stuff
To get it work you will need a couple helper files and config-snippets in your box.
The VRF and the static-interface/s you try to dial to, must be preconfigured.
The scripts grab a radius-realm from the username. So radius-realmname=vrf-name ...
"fury@ponnyhof" will dial to vrf 'ponnyhof'
"fury@mezgerei" will dial to vrf 'mezgerei'
### it is presumed that fury has access-rights to both realms on your radiusd ###
ppp-up
Code: Select all
:local localAddr $"local-address"
:local remoteAddr $"remote-address"
:local callerId $"caller-id"
:local calledId $"called-id"
:local interfaceName [/interface get $interface name]
:local calledRealm [:pick $user ([:find $user "@" ]+1) 60]
:local vrfId [/ip route vrf find where routing-mark=$calledRealm]
/ip route vrf print terse file=($calledRealm."Members") where routing-mark=$calledRealm
:local actualVrfIfs [/file get ($calledRealm."Members") contents] ;
:local actualExistentIfs [:pick $actualVrfIfs ([:find $actualVrfIfs "interfaces=" ]+11) ([:find $actualVrfIfs "route-distinguisher=" ]-1)]
/ip route vrf set $vrfId interfaces="$actualExistentIfs,$interfaceName"
:log info "$user (srcIp=$callerId, dstIp=$calledId) connected: was given $remoteAddr IP (GW $localAddr) and assigned to $interfaceName interface in VRF $calledRealm"
/file set ($calledRealm."Members") contents=""
/ip route vrf print terse file=($calledRealm."Members") where routing-mark=$calledRealmppp-down
Code: Select all
:local localAddr $"local-address"
:local remoteAddr $"remote-address"
:local callerId $"caller-id"
:local calledId $"called-id"
:local interfaceName [/interface get $interface name]
:local calledRealm [:pick $user ([:find $user "@" ]+1) 60]
:local vrfId [/ip route vrf find where routing-mark=$calledRealm]
/ip route vrf print terse file=($calledRealm."CleanUpMembers") where routing-mark=$calledRealm
:local cleanUpVrfIfs [/file get ($calledRealm."CleanUpMembers") contents] ;
:local lenInterfaceName [:len $interfaceName]
:local cleanUpExistentIfs ([:pick $cleanUpVrfIfs ([:find $cleanUpVrfIfs "interfaces=" ]+11) ([:find $cleanUpVrfIfs (",".$interfaceName) ] +0)]. \
[:pick $cleanUpVrfIfs ([:find $cleanUpVrfIfs $interfaceName ] + $lenInterfaceName) ([:find $cleanUpVrfIfs "route-distinguisher=" ]-1)])
:put $cleanUpExistentIfs
:put $lenInterfaceName
/ip route vrf set $vrfId interfaces="$cleanUpExistentIfs"
/file set ($calledRealm."CleanUpMembers") contents=""
/file set ($calledRealm."Members") contents=""
/ip route vrf print terse file=($calledRealm."Members") where routing-mark=$calledRealmGuess a global scheduled cleanup-script would also be usefull, to eleminate abandoned interfaces from failed log-on's and log-off's and 'poisoned' 'lock-file' content.
I'm not really the son of scripting-man ... so enhancements, opinions and testresults are highly appretiated.
######
some log-stuff:
Code: Select all
[admin@CHR_v6432] >
[admin@CHR_v6432] >
13:18:00 echo: ovpn,info TCP connection established from 192.168.67.92
[admin@CHR_v6432] >
13:18:01 echo: ovpn,info : using encoding - AES-256-CBC/SHA1
13:18:01 echo: ovpn,info,account fury-0@ponnyhof logged in, 172.23.24.19
[admin@CHR_v6432] >
13:18:01 echo: ovpn,info <ovpn-fury-0@ponnyhof>: connected
13:18:01 echo: system,info vrf ponnyhof changed
13:18:01 echo: script,info fury-0@ponnyhof (srcIp=192.168.67.92, dstIp=192.168.67.152) connected: was given 172.23.24.19 IP (GW 172.23.24.4) and assigned to <ovpn-fury-0@ponnyhof> interface in VRF ponnyhof
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] > /ip route vrf print terse
0 comment=ponnyhof routing-mark=ponnyhof interfaces=vlan666,<ovpn-fury-0@ponnyhof> route-distinguisher=1.1.1.6:66
1 comment=metzgerei routing-mark=metzgerei interfaces=vlan667 route-distinguisher=1.1.1.7:67
2 comment=neue routing-mark=neue interfaces=""
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
13:18:49 echo: ovpn,info <ovpn-fury-0@ponnyhof>: terminating... - peer disconnected
13:18:49 echo: system,info vrf ponnyhof changed
[admin@CHR_v6432] >
13:18:50 echo: ovpn,info,account fury-0@ponnyhof logged out, 49 10783 16 65 1
13:18:50 echo: ovpn,info <ovpn-fury-0@ponnyhof>: disconnected
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
13:20:16 echo: ovpn,info TCP connection established from 192.168.67.92
[admin@CHR_v6432] >
13:20:17 echo: ovpn,info : using encoding - AES-256-CBC/SHA1
13:20:17 echo: ovpn,info,account fury-0@metzgerei logged in, 172.23.24.29
13:20:17 echo: ovpn,info <ovpn-fury-0@metzgerei>: connected
13:20:17 echo: system,info vrf metzgerei changed
13:20:17 echo: script,info fury-0@metzgerei (srcIp=192.168.67.92, dstIp=192.168.67.152) connected: was given 172.23.24.29 IP (GW 172.23.24.3) and assigned to <ovpn-fury-0@metzgerei> interface in VRF metzgerei
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] > /ip route vrf print terse
0 comment=ponnyhof routing-mark=ponnyhof interfaces=vlan666 route-distinguisher=1.1.1.6:66
1 comment=metzgerei routing-mark=metzgerei interfaces=vlan667,<ovpn-fury-0@metzgerei> route-distinguisher=1.1.1.7:67
2 comment=neue routing-mark=neue interfaces=""
[admin@CHR_v6432] >
13:20:50 echo: ovpn,info <ovpn-fury-0@metzgerei>: terminating... - peer disconnected
13:20:50 echo: ovpn,info,account fury-0@metzgerei logged out, 33 10165 16 53 1
13:20:50 echo: ovpn,info <ovpn-fury-0@metzgerei>: disconnected
13:20:50 echo: system,info vrf metzgerei changed
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
13:21:54 echo: ovpn,info TCP connection established from 192.168.100.120
13:21:55 echo: ovpn,info : using encoding - AES-256-CBC/SHA1
13:21:55 echo: ovpn,info,account fury-1@ponnyhof logged in, 172.23.24.19
[admin@CHR_v6432] >
13:21:55 echo: ovpn,info <ovpn-fury-1@ponnyhof>: connected
13:21:55 echo: system,info vrf ponnyhof changed
13:21:55 echo: script,info fury-1@ponnyhof (srcIp=192.168.100.120, dstIp=192.168.67.152) connected: was given 172.23.24.19 IP (GW 172.23.24.6) and assigned to <ovpn-fury-1@ponnyhof> interface in VRF ponnyhof
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] > /ip route vrf print terse
0 comment=ponnyhof routing-mark=ponnyhof interfaces=vlan666,<ovpn-fury-1@ponnyhof> route-distinguisher=1.1.1.6:66
1 comment=metzgerei routing-mark=metzgerei interfaces=vlan667 route-distinguisher=1.1.1.7:67
2 comment=neue routing-mark=neue interfaces=""
[admin@CHR_v6432] >
13:22:35 echo: ovpn,info TCP connection established from 192.168.67.92
[admin@CHR_v6432] >
13:22:37 echo: ovpn,info : using encoding - AES-256-CBC/SHA1
13:22:37 echo: ovpn,info,account fury-0@ponnyhof logged in, 172.23.24.18
13:22:37 echo: ovpn,info <ovpn-fury-0@ponnyhof>: connected
13:22:37 echo: system,info vrf ponnyhof changed
13:22:37 echo: script,info fury-0@ponnyhof (srcIp=192.168.67.92, dstIp=192.168.67.152) connected: was given 172.23.24.18 IP (GW 172.23.24.4) and assigned to <ovpn-fury-0@ponnyhof> interface in VRF ponnyhof
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] > /ip route vrf print terse
0 comment=ponnyhof routing-mark=ponnyhof interfaces=vlan666,<ovpn-fury-1@ponnyhof>,<ovpn-fury-0@ponnyhof> route-distinguisher=1.1.1.6:66
1 comment=metzgerei routing-mark=metzgerei interfaces=vlan667 route-distinguisher=1.1.1.7:67
2 comment=neue routing-mark=neue interfaces=""
[admin@CHR_v6432] >
13:23:08 echo: ovpn,info <ovpn-fury-1@ponnyhof>: terminating... - peer disconnected
13:23:08 echo: system,info vrf ponnyhof changed
[admin@CHR_v6432] >
13:23:09 echo: ovpn,info,account fury-1@ponnyhof logged out, 74 3928 32 55 2
[admin@CHR_v6432] >
13:23:09 echo: ovpn,info <ovpn-fury-1@ponnyhof>: disconnected
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] > /ip route vrf print terse
0 comment=ponnyhof routing-mark=ponnyhof interfaces=vlan666,<ovpn-fury-0@ponnyhof> route-distinguisher=1.1.1.6:66
1 comment=metzgerei routing-mark=metzgerei interfaces=vlan667 route-distinguisher=1.1.1.7:67
2 comment=neue routing-mark=neue interfaces=""
[admin@CHR_v6432] >
13:23:25 echo: ovpn,info <ovpn-fury-0@ponnyhof>: terminating... - peer disconnected
13:23:25 echo: ovpn,info,account fury-0@ponnyhof logged out, 48 10160 16 53 1
13:23:25 echo: ovpn,info <ovpn-fury-0@ponnyhof>: disconnected
13:23:25 echo: system,info vrf ponnyhof changed
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] >
[admin@CHR_v6432] > /ip route vrf print terse
0 comment=ponnyhof routing-mark=ponnyhof interfaces=vlan666 route-distinguisher=1.1.1.6:66
1 comment=metzgerei routing-mark=metzgerei interfaces=vlan667 route-distinguisher=1.1.1.7:67
2 comment=neue routing-mark=neue interfaces=""
[admin@CHR_v6432] >Re: PPPoE & VRF
Testing with pppoe was not so golden ... the session-setup and close in pppoe is to fast to grab the named interface-name.
Figured that it's better to put a delay before reading the interface-name on a ppp-down-event and then to kill the whole shebang in the name of the zombie.
If you wanna use pppoe you should give a PADO-delay (around 1sec) for session-initiation, so grandpa is able to step into his scuffs.
The updatet ppp-down script works (for me) also with open-vpn, l2tp and sstp, mixed use is possible (had to copy the ppp-profile ... when I've used the same profile for different services I got quirky results).
.
ppp-down:
Figured that it's better to put a delay before reading the interface-name on a ppp-down-event and then to kill the whole shebang in the name of the zombie.
If you wanna use pppoe you should give a PADO-delay (around 1sec) for session-initiation, so grandpa is able to step into his scuffs.
The updatet ppp-down script works (for me) also with open-vpn, l2tp and sstp, mixed use is possible (had to copy the ppp-profile ... when I've used the same profile for different services I got quirky results).
.
ppp-down:
Code: Select all
:local localAddr $"local-address"
:local remoteAddr $"remote-address"
:local callerId $"caller-id"
:local calledId $"called-id"
:local interfaceName [/interface get $interface name]
:local calledRealm [:pick $user ([:find $user "@" ]+1) 60]
:local vrfId [/ip route vrf find where routing-mark=$calledRealm]
:delay 2
/ip route vrf print terse file=($calledRealm."CleanUpMembersSec") where routing-mark=$calledRealm
:local cleanUpVrfIfsSec [/file get ($calledRealm."CleanUpMembersSec") contents] ;
:local cleanUpExistentIfsSec ([:pick $cleanUpVrfIfsSec ([:find $cleanUpVrfIfsSec "interfaces=" ]+11) ([:find $cleanUpVrfIfsSec F00 ] -2)]. \
[:pick $cleanUpVrfIfsSec ([:find $cleanUpVrfIfsSec F00 ] + 6) ([:find $cleanUpVrfIfsSec "route-distinguisher=" ]-1)])
:put $cleanUpExistentIfsSec
/ip route vrf set $vrfId interfaces="$cleanUpExistentIfsSec"
/file set ($calledRealm."CleanUpMembersSec") contents=""
/file set ($calledRealm."Members") contents=""
/ip route vrf print terse file=($calledRealm."Members") where routing-mark=$calledRealmRe: PPPoE & VRF
Just learned, that the radius-attribute "Mikrotik-Group" is 'ppp-aware'.
So ... it seems Santa stays frosty up in Lappland this year, because you can (if you want) realize a radius-based VRF-selection with "Mikrotik-Group".
You have to skip the user-decidable realm-selection in the ppp-up/down scripts and then define the realm-(vrf-)name static in there.
Copy a profile for every VRF and adjust the realm-(vrf-)name -> ppp-profile-name corresponds with the radius-configured Mikrotik-Group attribute.
On your favorite radiusd configure the respective users with their respective "Mikrotik-Group"-attribute ( ... and all other things you need ... fw-chain-selector, specific address-pool) ... dun!
.
user-attributes ... or respective user-profile your favorite radiusd selects on basis of a wise policy for that user:
.
.
comment out the realm-picker in ppp-up & -down and define the realm static
.
If you plan to use the radius-based profile-selection, it should be possible to use a global variable to store the currently used interfaces in ppp-up & -down, because there's no need of a variable named reminder-space any longer and you can get rid of the helper-files.
So ... it seems Santa stays frosty up in Lappland this year, because you can (if you want) realize a radius-based VRF-selection with "Mikrotik-Group".
You have to skip the user-decidable realm-selection in the ppp-up/down scripts and then define the realm-(vrf-)name static in there.
Copy a profile for every VRF and adjust the realm-(vrf-)name -> ppp-profile-name corresponds with the radius-configured Mikrotik-Group attribute.
On your favorite radiusd configure the respective users with their respective "Mikrotik-Group"-attribute ( ... and all other things you need ... fw-chain-selector, specific address-pool) ... dun!
.
user-attributes ... or respective user-profile your favorite radiusd selects on basis of a wise policy for that user:
Code: Select all
Type Name Value
1. Radius:IETF Termination-Action = RADIUS-Request (1)
2. Radius:Mikrotik Mikrotik-Group = metzgerei
3. Radius:IETF Framed-Pool = metzgerei-pool
4. Radius:IETF Filter-Id = metzgerei-in.in
5. Click to add... .
comment out the realm-picker in ppp-up & -down and define the realm static
Code: Select all
#:local calledRealm [:pick $user ([:find $user "@" ]+1) 60]
:local calledRealm metzgereiIf you plan to use the radius-based profile-selection, it should be possible to use a global variable to store the currently used interfaces in ppp-up & -down, because there's no need of a variable named reminder-space any longer and you can get rid of the helper-files.
Re: PPPoE & VRF
... guess the attentive reader may have noticed, that the above scripts only do it's frugal duty in V6 of ROS ...
since V7 brings interesting features like wireguard and vxlan to the table, I humbly allowed myself now to adapt these scripts.
.
V7 brings also some features to simplify a vrf-dialin.
It's now possible to put an interface-list to a vrf, so that we can add an interface to an interface-list to achieve vrf-membership.
I've learned from staff-comments in the forum, that it is 'NOT MUCH' recommended to put dynamic-interfaces to a vrf ... please use and adapt this on your own risk.
.
exposition for these scripts:
- a user dials-in to PPP-service on the router with "user@realm", where realm is equal to the intended vrf the user wants to dial-in
- there is a preexisting vrf with name=realm
- there is a preexisting interface-list with name=realm
.
ppp-up:
.
... we strip the realm from user@realm ... and put the new dynamic-interface to the interface-list where name=realm ( ... and vrf=realm)
.
.
ppp-down
.
when the dynamic-interface is dissolved ... a "thing" is left in the form (example) *F0005F in the interface-list ... have'nt found out how this is fabricated ... maybe it's just a memory-address in the stack.
if users dial-in and dial-out ... "things" piling up ... so for every dial-out we remove a "thing" ... thats the ugly part ... also ... this may fail in certain situations
so an additional house-keeping script running in the low-profile hours might be useful
.
guess there is a lot space for enhancements !?
... enhance !
since V7 brings interesting features like wireguard and vxlan to the table, I humbly allowed myself now to adapt these scripts.
.
V7 brings also some features to simplify a vrf-dialin.
It's now possible to put an interface-list to a vrf, so that we can add an interface to an interface-list to achieve vrf-membership.
I've learned from staff-comments in the forum, that it is 'NOT MUCH' recommended to put dynamic-interfaces to a vrf ... please use and adapt this on your own risk.
.
exposition for these scripts:
- a user dials-in to PPP-service on the router with "user@realm", where realm is equal to the intended vrf the user wants to dial-in
- there is a preexisting vrf with name=realm
- there is a preexisting interface-list with name=realm
.
ppp-up:
Code: Select all
:local localAddr $"local-address"
:local remoteAddr $"remote-address"
:local callerId $"caller-id"
:local calledId $"called-id"
:local interfaceName [/interface get $interface name]
:local calledRealm [:pick $user ([:find $user "@" ]+1) 60]
/interface/list/member/add interface=$interfaceName list=$calledRealm
:log info "$user (Caller=$callerId, Called=$calledId) connected: Client: $remoteAddr IP Router-Local-IP: $localAddr, assigned to $interfaceName interface in VRF $calledRealm"
... we strip the realm from user@realm ... and put the new dynamic-interface to the interface-list where name=realm ( ... and vrf=realm)
.
.
ppp-down
Code: Select all
:local localAddr $"local-address"
:local remoteAddr $"remote-address"
:local callerId $"caller-id"
:local calledId $"called-id"
:local interfaceName [/interface get $interface name]
:local calledRealm [:pick $user ([:find $user "@" ]+1) 60]
:delay 4
/interface/list/member/remove numbers=[find where interface~"^.F00.*\$"]
when the dynamic-interface is dissolved ... a "thing" is left in the form (example) *F0005F in the interface-list ... have'nt found out how this is fabricated ... maybe it's just a memory-address in the stack.
if users dial-in and dial-out ... "things" piling up ... so for every dial-out we remove a "thing" ... thats the ugly part ... also ... this may fail in certain situations
so an additional house-keeping script running in the low-profile hours might be useful
.
guess there is a lot space for enhancements !?
... enhance !
Re: PPPoE & VRF
... by the way ... all my picky picking stuff in the V6-scripts is non-sense ...
using regex-stuff like below should have worked also in V6 ... just was'nt aware back then ...
.
[find where interface~"^.F00.*\$"]
.
question always asked every summer in scotland at loch ness ... "^.F00.*\$" ... but they do not use regex
... who's "Nessy" is what they wanna know for ages !!
using regex-stuff like below should have worked also in V6 ... just was'nt aware back then ...
.
[find where interface~"^.F00.*\$"]
.
question always asked every summer in scotland at loch ness ... "^.F00.*\$" ... but they do not use regex
... who's "Nessy" is what they wanna know for ages !!
Re: PPPoE & VRF
Had a chat recently with someone skilled in programming (C) ... he agreed that "F00***" might be some memory address leftover from the vrf-membership of the dynamic interface.
Since this is not happening, when a dynamic non-vrf interface is detached, it might be a problem only to remove the F00***-residue.
There might be inconsistencies left in the memory ... which be lead to instability ... eventually security-issues.
Negative consequence I've seen (v6): if the script which destroys the "leftover-interface" fails (whatever reasons, never cought it in the act), the F00***-residues will add up in the configuration.
When I tried to remove these residues (appear as unknown in WinBox), with WinBox ... the system went unaccessible ( maybe partionally crashed ). No problem when done with CLI.
So in short: use all this at your own risk.
Since this is not happening, when a dynamic non-vrf interface is detached, it might be a problem only to remove the F00***-residue.
There might be inconsistencies left in the memory ... which be lead to instability ... eventually security-issues.
Negative consequence I've seen (v6): if the script which destroys the "leftover-interface" fails (whatever reasons, never cought it in the act), the F00***-residues will add up in the configuration.
When I tried to remove these residues (appear as unknown in WinBox), with WinBox ... the system went unaccessible ( maybe partionally crashed ). No problem when done with CLI.
So in short: use all this at your own risk.
Re: PPPoE & VRF
@floaty
Great monologue
I am struggling to achieve the following.. Using an RB5009 v7.12.1 I would like to be able to connect 3 WAN connections (2x satellite + 1x mobile). As we need to keep of the traffic generated we need to establish 1 PPPoE connection per WAN and make sure traffic from pppoe-wan1 only passes out on WAN1, pppoe-wan2 -> WAN2, pppoe-wan3 -> WAN3.
We have two user groups, business which should be allowed access on any pppoe-wan connection, but priority is WAN1, followed by 2 and 3, the other group is the clients that should only be allowed access when WAN1/pppoe-wan1 is up.
For my test setup I have
WAN1 GW 101.10.10.1, WAN2 GW 202.10.10.1
pppoe-wan1 192.168.99.0/24, pppoe-wan2 192.168.199.0/24
business network 10.1.10.1/24
crew network (hotspot) 10.8.80.1
I've added the pppoe-wan1-client to VRFWAN1, but I'm not getting the traffic to flow out through the pppoe to the WAN connection, only by setting the WAN1 gateway directly as the route for VRFWAN1 the traffic flows but it does not register as traffic on the pppoe client so then we're unable to track the usage which we need.
Any pointers would be appreciated. Stay frosty
Great monologue
I am struggling to achieve the following.. Using an RB5009 v7.12.1 I would like to be able to connect 3 WAN connections (2x satellite + 1x mobile). As we need to keep of the traffic generated we need to establish 1 PPPoE connection per WAN and make sure traffic from pppoe-wan1 only passes out on WAN1, pppoe-wan2 -> WAN2, pppoe-wan3 -> WAN3.
We have two user groups, business which should be allowed access on any pppoe-wan connection, but priority is WAN1, followed by 2 and 3, the other group is the clients that should only be allowed access when WAN1/pppoe-wan1 is up.
For my test setup I have
WAN1 GW 101.10.10.1, WAN2 GW 202.10.10.1
pppoe-wan1 192.168.99.0/24, pppoe-wan2 192.168.199.0/24
business network 10.1.10.1/24
crew network (hotspot) 10.8.80.1
I've added the pppoe-wan1-client to VRFWAN1, but I'm not getting the traffic to flow out through the pppoe to the WAN connection, only by setting the WAN1 gateway directly as the route for VRFWAN1 the traffic flows but it does not register as traffic on the pppoe client so then we're unable to track the usage which we need.
Any pointers would be appreciated. Stay frosty
You do not have the required permissions to view the files attached to this post.
Re: PPPoE & VRF
<<@floaty>>
<<Great monologue>>
.
... cute ... the outside world is telling me so ...
both ... the v6 and the v7 ppp-dial.in and dial-out scripts ... are work-arounds to "lift" and "unlift" a dynamic ppp-interface into a VRF ... which is not officially supported in ROS6 and ROS7
.
your scheme looks like a firewall-problem ... mine was in the end the same ... and I solved it by dividing "parties" into vrf's ... because I have overlapping IP-spaces in my "WAN-X-destinations"
.
my need was a "dial-on-demand" into a L3-Network ... Authentication and Authorization is done by a radius-policy ... ( like: wanna come in VRF1 ? ... lets check your permissions and password ... and you're good to go ! )
.
your picture looks like ... a firewall issue ... ... on demand.
Some user-groups can "DIAL" destination WAN1 others can dial WAN2 ... and are allowed ... ... others may not
... different routing-tables are only needed when overlapping IP-space (routes) are in WAN'(x)s
like a VPN-access decision !?
.
So ... my scripts can do the job : ) ... but you need a radius-server instance, which lifts the "user-intent" into a network ... with a radius-policy ... unless you can identify the user-(intent) from a source-ip or something like that ... and stir it into the ppp-dial-in-script ...
.
a VRF makes things easy, when WAN1 and WAN2 ... MUST NOT have interconnections ... because you do not have to maintain firewall-policies then
.
otherwise ... things are possible ... but more complicated ... with the radius-attribute 'Filter-Id' you can control / ... manipulate the mikrotik-Firewall-policies for a PPP-session ... it's pure fun !
.
questions ? ... feelings ? ... suggestions ?
<<Great monologue
>>.
... cute ... the outside world is telling me so ...
both ... the v6 and the v7 ppp-dial.in and dial-out scripts ... are work-arounds to "lift" and "unlift" a dynamic ppp-interface into a VRF ... which is not officially supported in ROS6 and ROS7
.
your scheme looks like a firewall-problem ... mine was in the end the same ... and I solved it by dividing "parties" into vrf's ... because I have overlapping IP-spaces in my "WAN-X-destinations"
.
my need was a "dial-on-demand" into a L3-Network ... Authentication and Authorization is done by a radius-policy ... ( like: wanna come in VRF1 ? ... lets check your permissions and password ... and you're good to go ! )
.
your picture looks like ... a firewall issue ... ... on demand.
Some user-groups can "DIAL" destination WAN1 others can dial WAN2 ... and are allowed ... ... others may not
... different routing-tables are only needed when overlapping IP-space (routes) are in WAN'(x)s
like a VPN-access decision !?
.
So ... my scripts can do the job : ) ... but you need a radius-server instance, which lifts the "user-intent" into a network ... with a radius-policy ... unless you can identify the user-(intent) from a source-ip or something like that ... and stir it into the ppp-dial-in-script ...
.
a VRF makes things easy, when WAN1 and WAN2 ... MUST NOT have interconnections ... because you do not have to maintain firewall-policies then
.
otherwise ... things are possible ... but more complicated ... with the radius-attribute 'Filter-Id' you can control / ... manipulate the mikrotik-Firewall-policies for a PPP-session ... it's pure fun !
.
questions ? ... feelings ? ... suggestions ?
Re: PPPoE & VRF
unless you can identify the user-(intent) from a source-ip or something like that
.
I cannot believe that I said this ... ... you WILL IDENTIFY your user ... with proper credentials ... and a second factor ... you sloppy thing : )
.
I cannot believe that I said this ... ... you WILL IDENTIFY your user ... with proper credentials ... and a second factor ... you sloppy thing : )
Who is online
Users browsing this forum: No registered users and 4 guests