<<@floaty>>
<<Great monologue![:D]( "Very Happy")
>>
.
... 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 ?
Statistics: Posted by floaty — Sun Mar 10, 2024 6:06 am