How do I specify which IP is used for outgoing traffic

kevinds · Fri Jun 15, 2018 9:09 pm

Yeah, probably not clear from the title..

My Mikrotik routers have multiple IP addresses on different interfaces.. How do I specify which IP is used for outgoing traffic for the router itself?

For 'fetch' I can use src-address= but how do I set a default for all of the router's traffic.. 'Cloud Service' Updates, Packages-Updater, ect

CZFan · Fri Jun 15, 2018 9:32 pm

As per the routing table

kevinds · Fri Jun 15, 2018 9:39 pm

As per the routing table

Huh? Can you be a little more specific? Any hints?

My 0.0.0.0/0 route works for forwarding traffic, but RouterOS uses the wrong IP for it's own traffic, still going out the 0.0.0.0/8 route. My edge RouterOS, I need it to use a different 0.0.0.0/0 route than the forwarded traffic. My edge router, incoming traffic, say unsolicited from the internet, connects and works in both directions, but outgoing traffic originating from RouterOS uses a different IP.

CZFan · Sat Jun 16, 2018 1:31 am

What I am saying is traffic from the router will use same routes available to it as per what is in the routing table, same as traffic flowing through it, i.e. Forward.

Can you provide the route, nat and mangle rules to see where your problem can be.

kevinds · Sat Jun 16, 2018 3:18 am

What I am saying is traffic from the router will use same routes available to it as per what is in the routing table, same as traffic flowing through it, i.e. Forward.

Can you provide the route, nat and mangle rules to see where your problem can be.

Yes.. Which is what I expect, it is going to use the routing table.

I can assign the router multiple IP addresses on different interfaces.. How do I set which one it uses for it's own outgoing traffic?

As I said, with 'fetch' I can use src-address to specify the IP, how do i set this system wide for stuff like the package updater, DNS client, and the SNTP client?

Can you provide the route, nat and mangle rules to see where your problem can be.

If you really need it, I will get this together.. I have a feeling this is something I haven't set somewhere yet, or maybe just hoping.

The router doing NAT works great for the NAT'd traffic, but for it's own traffic, it picks an IP from an another interface which is not internet accessible.

CZFan · Sat Jun 16, 2018 12:57 pm

"The router doing NAT works great for the NAT'd traffic, but for it's own traffic, it picks an IP from an another interface which is not internet accessible."
That's what I meant, fix your routing / NATing, without you providing the necessary info, I can't guess where the problem is to correct it.

Else if you really want to put a plaster on it instead of correcting, you can try and add a mangle rule, with chain as output, connection state as new and action as mark routing = NFR (New From Router)
Add a default route with routing mark NFR to specified gateway IP

kevinds · Sat Jun 16, 2018 1:22 pm

You can try and add a mangle rule, with chain as output, connection state as new and action as mark routing = NFR (New From Router)
Add a default route with routing mark NFR to specified gateway IP

The problem is that this still doesn't set the IP used on the outgoing connection, just the gateway..

Right now my primary router is using an RFC1918 IP for the 0.0.0.0/0 route, which it is supposed to do, but also using it's own RFC1918 IP, rather than a public IP. I have a public /30 subnet that uses a private address for the next hop.

If I use the Ping tool it fails, until I also set the source IP. Same with fetch.

CZFan · Sat Jun 16, 2018 1:34 pm

Change the srcnat / masquerade rule to specify outgoing interface instead of source addresses, etc, should correct it

sindy · Sat Jun 16, 2018 11:12 pm

Each route has a parameter pref-src whose value specifies the local IP address of the router which should be used for locally originated packets sent down that route.

kevinds · Sun Jun 17, 2018 12:11 am

Each route has a parameter pref-src whose value specifies the local IP address of the router which should be used for locally originated packets sent down that route.

I was looking at that with the mangle suggestion.. Added a routing mark on the Output chain, setup a 0.0.0.0/0 route to the gateway with the pref-source one of the public IPs, but still failed..

Logging the traffic, it is adding the mark to all outgoing NAT'd traffic.. I don't see a way to separate just the traffic the router generates..

Am I seriously the first with this issue? I thought maybe just my search terms were lacking. Why do some tools have the ability to set the source address but not a place to set a default?

sindy · Sun Jun 17, 2018 10:25 am

The traffic the router generates itself goes through the output chain, the traffic which the router forwards goes through the forward chain. So a marking rule in chain=output only marks the traffic generated by the router itself, and a marking rule in chain=forward only marks the transit traffic. So if you only mark packets in chain=output and only src-nat the marked ones, the src-nat doesn't apply on the transit packets.

But how exactly do you test what is the source address of the packets as they leave your 'Tik? The point is that both the pref-src and src-nat normally do work, so do you use packet sniffing (capturing) on the 'Tik itself or on the destination device to visualise the actual source address or some other method?

anav · Mon Jun 18, 2018 6:58 pm

Post your config Kevinds, otherwise playing hide and seek is no fun with bits of information.

kevinds · Mon Jun 18, 2018 7:24 pm

Post your config Kevinds, otherwise playing hide and seek is no fun with bits of information.

I will be posting both routers' configuration today.

Literally doing the redactions now.

anav · Mon Jun 18, 2018 7:36 pm

Ha, I can only handle one router at a time............ x&Y chromosomes you know!

kevinds · Mon Jun 18, 2018 7:45 pm

Primary Router 2011UiAS

# model = 2011UiAS
/interface ethernet
set [ find default-name=ether1 ] 
set [ find default-name=ether2 ] 
set [ find default-name=ether3 ] 
set [ find default-name=ether4 ] 
set [ find default-name=ether5 ] 
set [ find default-name=ether6 ] 
set [ find default-name=ether7 ] 
set [ find default-name=ether8 ] 
set [ find default-name=ether9 ] 
set [ find default-name=ether10 ]
set [ find default-name=sfp1 ] mtu=1460
	
/ip address
add address=192.168.2.1/24 interface=ether2-bridge network=192.168.2.0
add address=172.18.2.1/30 interface=gre-Family1 network=172.18.2.0
add address=172.18.2.5/30 interface=gre-Family2 network=172.18.2.4
add address=172.18.2.13/30 interface=gre-Mikrotik-Mimic network=172.18.2.12
add address=172.18.2.9/30 interface=sfp1 network=172.18.2.8
add address=208.210.216.90/30 interface=ether3 network=208.210.216.88
add address=192.168.3.1/24 interface=ether7 network=192.168.3.0
add address=65.120.1.133/30 interface=ether3 network=65.120.1.132
add address=65.120.1.137/30 interface=ether4 network=65.120.1.136

/ip dns
set servers=8.8.8.8,192.168.2.6,192.168.2.20

/ip firewall address-list
add address=192.168.2.25 list=Allow-SMTP
add address=192.168.2.21 list=Allow-SMTP
add address=192.168.2.22 list=Allow-SMTP
add address=208.210.216.90 list=Allow-SMTP
add address=208.210.216.89 list=Allow-SMTP
add address=192.168.3.28 list=Allow-SMTP

/ip firewall filter
add action=drop chain=input comment="Drop Invalid" connection-state=invalid
add action=drop chain=forward comment="Drop Invalid" connection-state=invalid
add action=accept chain=forward comment="SMTP-Allow Outgoing" dst-port=25 \
    protocol=tcp src-address-list=Allow-SMTP
add action=accept chain=forward comment="SMTP-Allow Incoming" \
    dst-address-list=Allow-SMTP dst-port=25 protocol=tcp
add action=accept chain=forward comment="SMTP Drop" dst-port=25 log=yes \
    protocol=tcp
add action=drop chain=forward comment="Drop Cam AM Packet" packet-mark=\
    Cameron time=0s-12h,sun,mon,tue,wed,thu,fri,sat
# inactive time
add action=drop chain=forward comment="Drop Cam PM Packet" packet-mark=\
    Cameron time=22h-23h59m59s,sun,mon,tue,wed,thu,fri,sat
add action=accept chain=input
add action=accept chain=forward
/ip firewall mangle
add action=mark-routing chain=output disabled=yes new-routing-mark=Heatwave \
    passthrough=no src-address=173.254.239.128/26
add action=mark-packet chain=prerouting comment="Phone Block" \
    new-packet-mark=Cameron passthrough=yes src-mac-address=D8:6C:02:96:3E:D2
add action=mark-packet chain=prerouting comment="3DS Block" new-packet-mark=\
    Cameron passthrough=yes src-mac-address=40:F4:07:DB:CD:93
add action=mark-packet chain=prerouting comment="Ethernet Block" \
    new-packet-mark=Cameron passthrough=yes src-mac-address=34:97:F6:68:77:CF
add action=mark-packet chain=prerouting comment="Netgear Block" \
    new-packet-mark=Cameron passthrough=yes src-mac-address=E0:91:F5:95:B3:C6
add action=mark-packet chain=prerouting comment="WiFi Block" new-packet-mark=\
    Cameron passthrough=yes src-mac-address=00:1F:D0:4A:7B:62
add action=mark-packet chain=prerouting comment=Spare disabled=yes \
    new-packet-mark=Cameron passthrough=yes src-mac-address=7C:2F:80:E5:AC:7D
/ip firewall nat
add action=src-nat chain=srcnat dst-address=172.18.2.10 to-addresses=\
    172.18.2.9
add action=accept chain=srcnat dst-address=192.168.0.0/16
add action=accept chain=srcnat dst-address=172.16.0.0/12
add action=src-nat chain=srcnat comment="mail.example.com Outgoing NAT" \
    src-address=192.168.3.0/24 to-addresses=208.210.216.89
add action=dst-nat chain=dstnat comment="mail.example.com Incoming Traffic" \
    dst-address=208.210.216.89 to-addresses=192.168.3.28
add action=src-nat chain=srcnat comment="Robin Outgoing NAT rule" disabled=\
    yes src-address=192.168.2.21 to-addresses=69.165.226.53
add action=src-nat chain=srcnat comment="Batman Outgoing NAT rule" disabled=\
    yes src-address=192.168.2.22 to-addresses=69.165.226.54
add action=src-nat chain=srcnat comment="Main Outgoing NAT rule" src-address=\
    192.168.2.0/24 to-addresses=208.210.216.90
add action=dst-nat chain=dstnat comment="Batman Incoming 143" dst-address=\
    208.210.216.90 dst-port=143 protocol=tcp to-addresses=192.168.2.22 \
    to-ports=143
add action=dst-nat chain=dstnat comment="Batman Incoming 110" dst-address=\
    208.210.216.90 dst-port=110 protocol=tcp to-addresses=192.168.2.22 \
    to-ports=110
add action=dst-nat chain=dstnat comment="Batman Incoming 443" dst-address=\
    208.210.216.90 dst-port=443 protocol=tcp to-addresses=192.168.2.22 \
    to-ports=443
add action=dst-nat chain=dstnat comment="Batman Incoming 587" dst-address=\
    208.210.216.90 dst-port=587 protocol=tcp to-addresses=192.168.2.22 \
    to-ports=587
add action=dst-nat chain=dstnat comment="QNAP SSH" dst-address=208.210.216.90 \
    dst-port=223 protocol=tcp to-addresses=192.168.2.25 to-ports=22
add action=dst-nat chain=dstnat comment="Robin Incoming 25" dst-address=\
    208.210.216.90 dst-port=25 protocol=tcp to-addresses=192.168.2.21 \
    to-ports=25
add action=dst-nat chain=dstnat comment="Incoming SSH" dst-address=\
    208.210.216.90 dst-port=22 protocol=tcp to-addresses=192.168.2.14 \
    to-ports=22
add action=dst-nat chain=dstnat disabled=yes dst-address=184.64.32.79 \
    dst-port=25 protocol=tcp to-addresses=192.168.2.21 to-ports=25
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=53 \
    protocol=udp to-addresses=192.168.2.14 to-ports=1196
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=53 \
    protocol=tcp to-addresses=192.168.2.14 to-ports=943
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=69 \
    protocol=udp to-addresses=192.168.2.25 to-ports=69
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=80 \
    protocol=tcp to-addresses=192.168.2.22 to-ports=80
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=81 \
    protocol=tcp to-addresses=192.168.2.25 to-ports=80
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=110 \
    protocol=tcp to-addresses=192.168.2.22 to-ports=110
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=143 \
    protocol=tcp to-addresses=192.168.2.22 to-ports=143
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=443 \
    protocol=tcp to-addresses=192.168.2.22 to-ports=443
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=514 \
    protocol=udp to-addresses=192.168.2.12 to-ports=514
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=514 \
    protocol=tcp to-addresses=192.168.2.12 to-ports=514
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=943 \
    protocol=tcp to-addresses=192.168.2.14 to-ports=943
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=993 \
    protocol=tcp to-addresses=192.168.2.22 to-ports=993
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=995 \
    protocol=tcp to-addresses=192.168.2.22 to-ports=995
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=1194 \
    protocol=udp to-addresses=192.168.2.14 to-ports=1194
add action=dst-nat chain=dstnat disabled=yes dst-address=184.64.32.79 \
    dst-port=1194 protocol=udp to-addresses=192.168.2.14 to-ports=1194
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=1194 \
    protocol=tcp to-addresses=192.168.2.14 to-ports=1194
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=1196 \
    protocol=udp to-addresses=192.168.2.14 to-ports=1196
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=1196 \
    protocol=tcp to-addresses=192.168.2.14 to-ports=943
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=8282 \
    protocol=tcp to-addresses=192.168.2.25 to-ports=8282
add action=dst-nat chain=dstnat comment="Heatwave Winbox" disabled=yes \
    dst-address=208.210.216.90 dst-port=8292 protocol=tcp to-addresses=\
    172.18.2.10 to-ports=8291
add action=dst-nat chain=dstnat dst-address=208.210.216.90 dst-port=8243 \
    protocol=tcp to-addresses=192.168.2.25 to-ports=8243
add action=dst-nat chain=dstnat disabled=yes dst-address=184.64.32.79 \
    dst-port=10000 protocol=tcp to-addresses=192.168.2.14 to-ports=10000
add action=dst-nat chain=dstnat disabled=yes dst-address=69.165.226.49 \
    dst-port=3389 protocol=tcp to-addresses=192.168.2.126 to-ports=3389
/ip firewall service-port
set sip disabled=yes

/ip route
add distance=1 gateway=172.18.2.10 pref-src=208.210.216.90 routing-mark=NFR
add distance=1 gateway=172.18.2.10
add distance=1 dst-address=192.168.12.0/24 gateway=172.16.211.18
add distance=1 dst-address=192.168.15.0/24 gateway=172.16.211.18
add distance=1 dst-address=192.168.17.0/24 gateway=172.18.2.6
add distance=1 dst-address=192.168.20.0/24 gateway=172.18.2.10
add distance=1 dst-address=192.168.88.0/24 gateway=172.18.2.10
add distance=1 dst-address=192.168.128.0/24 gateway=*36
add distance=1 dst-address=192.168.200.0/24 gateway=172.18.2.2

/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=ether2-bridge type=internal
add forced-ip=208.210.216.90 interface=sfp1 type=external

Edge Router RB750Gr3

# model = RouterBOARD 750G r3

/interface pppoe-client
add add-default-route=yes default-route-distance=25 interface=ether4 name=\
    pppoe-out1 password=kevinds user=kevinds@pppoe.net

/interface l2tp-client
add add-default-route=yes connect-to=209.205.90.194 disabled=no name=\
    Static-IP-VPN password=kevindsL2TP profile=default user=svpn.kevinds@pppoe.net

/ip address
add address=172.18.2.10/30 interface=ether3 network=172.18.2.8

/ip dhcp-client
add add-default-route=special-classless default-route-distance=20 dhcp-options=hostname,clientid disabled=no interface=ether1

/ip firewall address-list
add address=1.109.178.156 list="sbl blocklist.de"
add address=95.181.219.0/24 list="sbl spamhaus"
add address=109.248.9.0/24 list="sbl dshield"
add address=241.0.10.0/24 list="custome-block"

/ip firewall filter
add action=drop chain=forward connection-state=invalid
add action=drop chain=input connection-state=invalid

/ip firewall raw
add action=drop chain=prerouting comment="memcached - TCP" dst-port=11211 protocol=tcp
add action=drop chain=prerouting comment="memcached - UDP" dst-port=11211 protocol=udp
add action=accept chain=prerouting comment="209.205.90.194 Bypass" src-address=209.205.90.194
add action=drop chain=prerouting src-address-list="sbl blocklist.de"
add action=drop chain=prerouting src-address-list="sbl spamhaus"
add action=drop chain=prerouting src-address-list="sbl dshield"
add action=drop chain=prerouting src-address-list=custom-block

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes

/ip route
add distance=1 dst-address=65.120.1.132/28 gateway=172.18.2.9
add distance=1 dst-address=172.16.0.0/12 gateway=172.18.2.9
add distance=1 dst-address=192.168.0.0/16 gateway=172.18.2.9
add distance=1 dst-address=208.210.216.88/30 gateway=172.18.2.9
add distance=1 dst-address=209.205.90.194/32 gateway=172.103.193.1


/system clock
set time-zone-autodetect=no time-zone-name=America/Edmonton

/system routerboard settings
set silent-boot=no

/system scheduler
add interval=30m name="Fetch Blacklist" on-event="/tool fetch address=www.squi\
    dblacklist.org host=www.squidblacklist.org mode=http src-path=/downloads/d\
    rop.malicious.rsc src-address=172.103.193.102" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=may/20/1979 start-time=00:15:00
add interval=30m name="Import Blacklist" on-event=\
    "/import file-name=drop.malicious.rsc" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=may/20/2018 start-time=00:18:13

The Edge router uses the VPN connection, which also gives a RFC1918 IP, and the VPN server does NAT for.. The VPN server is a 'bad' IP on the internet (why I put the bypass into the Mangle rules) so connections are often refused when using the VPN server's public IP for connections. Using the source-IP as the DHCP IP, using the source-IP from the DHCP (cable) or PPPoE (DSL) fixes this. The Cloud DDNS update though, uses the VPN server IP, which then can't be used to remotely connect..

Yes, cable and DSL, when one goes down, I manually switch over to the other connection.. Figuring out automated switching is planned for the future.

kevinds · Mon Jun 18, 2018 8:23 pm

The traffic the router generates itself goes through the output chain, the traffic which the router forwards goes through the forward chain. So a marking rule in chain=output only marks the traffic generated by the router itself, and a marking rule in chain=forward only marks the transit traffic. So if you only mark packets in chain=output and only src-nat the marked ones, the src-nat doesn't apply on the transit packets.

But how exactly do you test what is the source address of the packets as they leave your 'Tik? The point is that both the pref-src and src-nat normally do work, so do you use packet sniffing (capturing) on the 'Tik itself or on the destination device to visualise the actual source address or some other method?

So if you only mark packets in chain=output and only src-nat the marked ones, the src-nat doesn't apply on the transit packets.

I didn't src-nat the marked ones, I setup a routing-mark, and setup a route for the marked traffic. As per CZFan

But how exactly do you test what is the source address of the packets as they leave your 'Tik?
Mikrotik's Cloud DDNS was an easy way on my edge router, after trying to figure out why some traffic was blocked and other's wasn't (VPN server's public IP frequently gets blacklisted)

sindy · Mon Jun 18, 2018 9:15 pm

But how exactly do you test what is the source address of the packets as they leave your 'Tik?
Mikrotik's Cloud DDNS was an easy way on my edge router, after trying to figure out why some traffic was blocked and other's wasn't (VPN server's public IP frequently gets blacklisted)

Well, I'm afraid that might be another can of worms, as I have no idea which of the local addresses the Mikrotik Cloud DDNS client choses to indicate as the WAN one in the body of the DDNS update. So in the warning coming back, DDNS server received request from IP 123.123.123.123 but your local IP was 192.168.88.23; DDNS service might not work, the 123.123.123.123 is the address from which the request actually came, so it should be your 208.x.x.90 if the pref-src on the routing-marked route works properly (are you sure you wanted to publish all your public IPs here)? I'm not sure whether the DDNS client looks at pref-src of the route towards the DDNS server when creating the update request. But if it does, it is for sure the route with no routing mark (the client definitely doesn't analyse the configuration completely to find out that the update request will be routed using a marked route).

kevinds · Mon Jun 18, 2018 9:44 pm

But how exactly do you test what is the source address of the packets as they leave your 'Tik?
Mikrotik's Cloud DDNS was an easy way on my edge router, after trying to figure out why some traffic was blocked and other's wasn't (VPN server's public IP frequently gets blacklisted)
Well, I'm afraid that might be another can of worms, as I have no idea which of the local addresses the Mikrotik Cloud DDNS client choses to indicate as the WAN one in the body of the DDNS update. So in the warning coming back, DDNS server received request from IP 123.123.123.123 but your local IP was 192.168.88.23; DDNS service might not work, the 123.123.123.123 is the address from which the request actually came, so it should be your 208.x.x.90 if the pref-src on the routing-marked route works properly (are you sure you wanted to publish all your public IPs here)? I'm not sure whether the DDNS client looks at pref-src of the route towards the DDNS server when creating the update request. But if it does, it is for sure the route with no routing mark (the client definitely doesn't analyse the configuration completely to find out that the update request will be routed using a marked route).

are you sure you wanted to publish all your public IPs here)?

I don't like posting this much of my configuration in general, why I was so hesitant.. But part of my redaction process, I changed all the IPs, RFC1918 and public IPs, except the last octet so I could still read and keep track of them in this discussion. Normally I would use RFC5737 IPs.

Otherwise, that is my original question.. How do I specify a default source-IP for the router's own traffic.

anav · Mon Jun 18, 2018 9:53 pm

The router isnt designed to forward traffic from itself, traffic is forwarded through the router internet to lan or lan to internet.
Traffic to the router is input chain, traffic out of the router is output chain.
Input and output I see as administrative chains not to be used for the bulk of router work (forwarding).

I am much to green to contemplate using marks in source NAT rules, in fact I think thats fundamentally wrong.
Use routes to determine where traffic goes forwarded to the WAN.
Use marks in routes to isolate source on router to specific output IPs.
SrcNat is to identify public IP associated with traffic going out that WAN interface (to translate private IPs and then return traffic to same private IP).
It is not the funtion of source nat to identify the sources from my limited experience.
DstNat is to direct where unsolicited traffic is forwarded to when it reaches the router

sindy · Mon Jun 18, 2018 9:54 pm

Otherwise, that is my original question.. How do I specify a default source-IP for the router's own traffic.

I bear this in mind all the time. What I wanted to point out was that the actual source address of router's own traffic, placed to the IP header of the packet, is one thing and is handled by the routing process (by means of pref-src) and/or by the firewall (by means of src-nat), but the address indicated in the payload of the DDNS update request is a different thing and I don't know how the associated magic works. So if it is not too complex, disable the routing-marking rule per @CZfan, set pref-src on the default route in the default routing table (i.e. the default route with no routing-mark) to the address you want to registed using DDNS, and try again. And feed back whether you've got the warning message from the cloud DDNS or not and if yes, paste it here after substituting the real addresses by the aliases you've used in your config export.

kevinds · Mon Jun 18, 2018 10:13 pm

I think I solved it with your src-nat suggestion, not needing another route at all..

I made an address list with the three RFC1918 ranges,

Added a mangle rule to mark connections new connections not from the RFC1918 list

Added a src-nat rule at the top for the marked connections with a src-nat action to the IP I wanted.

Working on both routers, I think I'll have to remember it on the edge-router to switch between cable and DSL.

Need to tweak the edge router to use the DHCP client IP, rather than the statically set one, masquerade perhaps, but I need to lookup how to enter it to use the correct interface.

kevinds · Mon Jun 18, 2018 11:02 pm

Working on both routers

Edit: It isn't working on the edge router

DDNS server received request from IP 209.205.90.194 but your local IP was 172.16.3.23; DDNS service might not work

172.16.3.23 is the dynamic IP from the L2TP connection, 209.205.90.194 is the VPN server

If I turn on the src-nat rule, it times out instead, I can see the traffic counter increasing

Mangle rule showing 128,000 packets so far, NAT rule showing 53..

Edit: Edit: Enabled/disabled the src-nat rule, disabled/enabled the masquerade rule, and it is working again..

sindy · Mon Jun 18, 2018 11:43 pm

Code: Select all
DDNS server received request from IP 209.205.90.194 but your local IP was 172.16.3.23; DDNS service might not work
172.16.3.23 is the dynamic IP from the L2TP connection, 209.205.90.194 is the VPN server

Well, in this case, if adding the default route is permitted for the /interface l2tp-client, the behaviour above makes a perfect sense - the default gateway becomes the L2TP interface as soon as the L2TP tunnel gets up, the DDNS client finds the local address matching the default route's gateway interface (the L2TP one) and sends an update request to the DDNS server via that gateway. As the VPN server does not assign the public IP to the Mikrotik end of the tunnel (as some other VPN servers do) but instead assigns a private IP to it an performs a src-nat to its own public address before routing the packet to the internet, it doesn't matter what the Mikrotik sets as source address in the packet because the VPN server always overwrites that with its own public address.

kevinds · Tue Jun 19, 2018 12:28 am

As the VPN server does not assign the public IP to the Mikrotik end of the tunnel (as some other VPN servers do) but instead assigns a private IP to it an performs a src-nat to its own public address before routing the packet to the internet, it doesn't matter what the Mikrotik sets as source address in the packet because the VPN server always overwrites that with its own public address.

Correct, but if it did as it was told and use the ether1's DHCP as the source and ether1 as the outgoing interface, all would good.

Incoming traffic from the internet to the edge router, will connect and work. If it was following the route list, it wouldn't work. (Why I set classless for the DHCP aquired route). I only needed to add the VPN server IP to the routing table for the DSL connection.

I will play with this more this evening.

Because I can have incoming connections to the DHCP IP on ether1, I want to use a monitoring service to monitor the VPN IPs and the DHCP IP to track outages. Determine which is failing during an outage. Use the Cloud DDNS client to update the IP.

sindy · Tue Jun 19, 2018 2:17 pm

Correct, but if it did as it was told and use the ether1's DHCP as the source and ether1 as the outgoing interface, all would good.

But then it is a routing issue, not source address choice issue.

You may have missed that route choice is always the first thing the machine does, the source address choice only comes next. So you cannot say "use this source address" and expect that the machine will choose a route among those which have that address set as pref-src. So it is your routes' configuration what must guarantee that the gateway provided by dhcp-client on ether1 will always be used for the DDNS update. I don't know the purpose of the VPN tunnel, but if it is not intended to replace the default gateway whenever it comes up, either tell it not to add its own default route at all or at least tell it to add it with distance parameter value higher than the one provided by the ether1 dhcp-client's default route so it will only be used if ether1 goes down.

Creating a dedicated route to the DDNS server may be a more complex task as it seems it can change from time to time.

kevinds · Tue Jun 19, 2018 8:13 pm

I don't know the purpose of the VPN tunnel, but if it is not intended to replace the default gateway whenever it comes up, either tell it not to add its own default route at all or at least tell it to add it with distance parameter value higher than the one provided by the ether1 dhcp-client's default route so it will only be used if ether1 goes down.

Creating a dedicated route to the DDNS server may be a more complex task as it seems it can change from time to time.

Can of worms might be the right description.. haha

The VPN tunnel provides the static blocks for my primary router. I set classless and then the distance higher on the DHCP client so it has a route to the VPN server and then the VPN default route takes over..

You may have missed that route choice is always the first thing the machine does, the source address choice only comes next. So you cannot say "use this source address" and expect that the machine will choose a route among those which have that address set as pref-src.

What I really don't understand is how incoming traffic to the DHCP IP 'works' when the active default route is the VPN. Plus if I change the source-IP, it does take the different route, so it isn't just based on the routes.

kevinds · Tue Jun 19, 2018 8:21 pm

I don't know the purpose of the VPN tunnel, but if it is not intended to replace the default gateway whenever it comes up, either tell it not to add its own default route at all or at least tell it to add it with distance parameter value higher than the one provided by the ether1 dhcp-client's default route so it will only be used if ether1 goes down.

Creating a dedicated route to the DDNS server may be a more complex task as it seems it can change from time to time.

Can of worms might be the right description.. haha

The VPN tunnel provides the static blocks for my primary router. I set classless and then the distance higher on the DHCP client so it has a route to the VPN server and then the VPN default route takes over..

You may have missed that route choice is always the first thing the machine does, the source address choice only comes next. So you cannot say "use this source address" and expect that the machine will choose a route among those which have that address set as pref-src.

This is exactly what I am doing with fetch is it not?

What I really don't understand is how incoming traffic to the DHCP IP 'works' when the active default route is the VPN. Plus if I change the source-IP, it does take the different route, so it isn't just based on the routes.

anav · Wed Jun 20, 2018 12:50 am

Well as I found out its not called anavOS or kevindsOS its RouterOS and it has rules LOL.

kevinds · Wed Jun 20, 2018 2:13 am

Well as I found out its not called anavOS or kevindsOS its RouterOS and it has rules LOL.

Of course it has rules, but it would be a lot easier if I knew what these rules were and why they only seem to be followed sometimes and not others.

I still can not figure out why I can establish connections to the DHCP provided IP from the wild internet when the default route is over the VPN connection. If I am following everything correctly, the responses should be sent over the VPN, dropping the connection. I thought I was decent at networking stuff, just the different brand configurations/implementations being the issue, but I am seriously at a loss on this one.

anav · Wed Jun 20, 2018 2:56 am

What kind of VPN are you using. Try EOIP with security enabled and see if that owrks.........

kevinds · Wed Jun 20, 2018 3:04 am

What kind of VPN are you using. Try EOIP with security enabled and see if that owrks.........

L2TP.. It is in my config above..

It is set by my VPN provider, they provide my static IPs,

EoIP with security enabled? IPSec? But to see if what works?

I want to understand why/how it is working now.. I thought it was the 'classless' setting, but thinking about it more, that shouldn't affect it

CZFan · Wed Jun 20, 2018 12:29 pm

Well as I found out its not called anavOS or kevindsOS its RouterOS and it has rules LOL.
Of course it has rules, but it would be a lot easier if I knew what these rules were and why they only seem to be followed sometimes and not others.

I still can not figure out why I can establish connections to the DHCP provided IP from the wild internet when the default route is over the VPN connection. If I am following everything correctly, the responses should be sent over the VPN, dropping the connection. I thought I was decent at networking stuff, just the different brand configurations/implementations being the issue, but I am seriously at a loss on this one.

It will reply to the same IP / Interface it came in on, that is how networking / routing work, and not Mikrotik speciic

sindy · Wed Jun 20, 2018 1:47 pm

It will reply to the same IP / Interface it came in on, that is how networking / routing work, and not Mikrotik speciic

@CZFan, I'm afraid that responding from the same local IP address to which the request came (which definitely works) and choosing for the response the backward route via the same interface through which the request came in (which should not work automatically) are two different things.

I want to understand why/how it is working now.. I thought it was the 'classless' setting, but thinking about it more, that shouldn't affect it

@kevinds, can you post the result of /ip route print detail taken while the L2TP tunnel is up, of course after sanitizing it? I suspect that the system chooses from several routes with equal distance in a round-robin fashion so it sometimes works and sometimes doesn't.

anav · Wed Jun 20, 2018 3:12 pm

My bad Kevinds, I didnt realize it was not a real VPN LOL. The kind where you control both ends of the stick. Relying on a "retail" operation from another source may not be the best approach as you have no control over how they manipulate their infrastructure on a day to day basis. I am also not sure if third party vendors can be trusted with your top secret information

.
In any case, a network discussion way above my pay grade.

kevinds · Wed Jun 20, 2018 6:57 pm

@kevinds, can you post the result of /ip route print detail taken while the L2TP tunnel is up, of course after sanitizing it? I suspect that the system chooses from several routes with equal distance in a round-robin fashion so it sometimes works and sometimes doesn't.

ip route print detail

[kevinds@MikroTik] > /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - pr
 0 ADS  dst-address=0.0.0.0/0 gateway=Static-IP-VPN gateway-status=Static-IP-VPN reachable distance=1 scope=30 target-scope=10 

 1  DS  dst-address=0.0.0.0/0 gateway=172.103.193.1 gateway-status=172.103.193.1 reachable via  ether1 distance=20 scope=30 target-scope=10 vr

 2 ADC  dst-address=10.0.0.1/32 pref-src=172.16.2.23 gateway=Static-IP-VPN gateway-status=Static-IP-VPN reachable distance=0 scope=10 

 3 A S  dst-address=65.120.1.132/28 gateway=172.18.2.9 gateway-status=172.18.2.9 reachable via  ether3 distance=1 scope=30 target-scope=10 
 
 4 A S  dst-address=172.16.0.0/12 gateway=172.18.2.9 gateway-status=172.18.2.9 reachable via  ether3 distance=1 scope=30 target-scope=10 

 5 ADC  dst-address=172.18.2.8/30 pref-src=172.18.2.10 gateway=ether3 gateway-status=ether3 reachable distance=0 scope=10 

 6 ADC  dst-address=172.103.193.0/26 pref-src=172.103.193.102 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10 

 7 A S  dst-address=192.168.0.0/16 gateway=172.18.2.9 gateway-status=172.18.2.9 reachable via  ether3 distance=1 scope=30 target-scope=10 

 8 A S  dst-address=208.210.216.88/30 gateway=172.18.2.9 gateway-status=172.18.2.9 reachable via  ether3 distance=1 scope=30 target-scope=10 

 9 ADS  dst-address=209.205.90.194/32 gateway=172.103.193.1 gateway-status=172.103.193.1 reachable via  ether1 distance=0 scope=30 target-scop

 10  S  dst-address=209.205.90.194/32 gateway=pppoe-out1 gateway-status=pppoe-out1 unreachable distance=1 scope=30 target-scope=10 
[kevinds@MikroTik] >

kevinds · Wed Jun 20, 2018 7:02 pm

My bad Kevinds, I didnt realize it was not a real VPN LOL. The kind where you control both ends of the stick. Relying on a "retail" operation from another source may not be the best approach as you have no control over how they manipulate their infrastructure on a day to day basis. I am also not sure if third party vendors can be trusted with your top secret information .
In any case, a network discussion way above my pay grade.

I tried, but finding the right combination of network performance (latency and jitter), larger static IP blocks, transfer allowance, and affordability was a challenge. I had a dedicated server in LA for a bit that met most of the requirements except the jitter was unacceptable and made VoIP unusable...

The VPN isn't for anonymity, it is for the static IP blocks... I'm open to other providers.

How do I specify which IP is used for outgoing traffic

How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Re: How do I specify which IP is used for outgoing traffic

Who is online