Community discussions

 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Ping IPSEC host from router

Sat Apr 20, 2019 8:12 pm

I have an IPSEC VPN to a non-Mikrotik device. I can ping between hosts on the branch and corp networks, but I can't ping from the branch Mikrotik to a host on the corp network. I have tried specifying the Mikrotik's LAN address as the src-address to no avail. I know there are some tricks to force traffic through the policy, but if I can't ping using src-address I'm not convinced anything will work.
My config (IP only):
# apr/20/2019 11:35:49 by RouterOS 6.44.2
# software id = UFWD-1G10
#
# model = RouterBOARD 1100x4
/ip ipsec profile
add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 lifetime=\
    8h name=profile_1 nat-traversal=no
/ip ipsec peer
add address={corp_public_net}.230/32 comment=Corp name=peer1 profile=profile_1
/ip ipsec proposal
add enc-algorithms=aes-256-cbc lifetime=1h name=corp pfs-group=none
/ip pool
add name=dhcp ranges=192.168.1.101-192.168.1.200
/ip dhcp-server
add address-pool=dhcp authoritative=after-2sec-delay disabled=no interface=\
    "bridge1(LAN)" lease-time=1h name=dhcp1
/ip address
add address=192.168.1.1/24 interface="bridge1(LAN)" network=192.168.1.0
add address={branch_public_net}.31/24 interface="ether13(WAN)" network={branch_public_net}.0
/ip dhcp-client
add dhcp-options=hostname,clientid interface=ether1
/ip dhcp-server config
set store-leases-disk=never
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=192.168.1.12,192.168.1.14 gateway=\
    192.168.1.1 netmask=24
/ip dns
set servers=8.8.8.8
/ip firewall address-list
add address=0.0.0.0/8 comment=RFC6890 list=NotPublic
add address=10.0.0.0/8 comment=RFC6890 list=NotPublic
add address=100.64.0.0/10 comment=RFC6890 list=NotPublic
add address=127.0.0.0/8 comment=RFC6890 list=NotPublic
add address=169.254.0.0/16 comment=RFC6890 list=NotPublic
add address=172.16.0.0/12 comment=RFC6890 list=NotPublic
add address=192.0.0.0/24 comment=RFC6890 list=NotPublic
add address=192.0.2.0/24 comment=RFC6890 list=NotPublic
add address=192.168.0.0/16 comment=RFC6890 list=NotPublic
add address=192.88.99.0/24 comment=RFC3068 list=NotPublic
add address=198.18.0.0/15 comment=RFC6890 list=NotPublic
add address=198.51.100.0/24 comment=RFC6890 list=NotPublic
add address=203.0.113.0/24 comment=RFC6890 list=NotPublic
add address=224.0.0.0/4 comment=RFC4601 list=NotPublic
add address=240.0.0.0/4 comment=RFC6890 list=NotPublic
add address=192.168.1.0/24 list=admin_nets
add address={corp_public_net}.230 list=admin_nets
add address={corp_public_net}.230 list=corp
add address=10.24.8.0/21 list=corp_nets
add address=192.168.53.0/24 list=corp_nets
add address=192.168.1.0/24 list=local_nets
/ip firewall filter
add action=drop chain=input comment="Drop invalid packets" connection-state=\
    invalid
add action=drop chain=input comment="Drop all packets from public internet which\
    \_should not exist in public network" in-interface-list=WAN \
    src-address-list=NotPublic
add action=accept chain=input comment="Accept established and related packets" \
    connection-state=established,related
add chain=input comment="Accept all connections from local network" \
    in-interface-list=LAN
add action=accept chain=input comment="Allow remote webfig" disabled=yes \
    dst-port=8443 protocol=tcp
add action=accept chain=input comment="Accept IPSEC udp 500" dst-port=500 \
    protocol=udp
add action=accept chain=input comment="Accept IPSEC udp 4500" dst-port=4500 \
    protocol=udp
add action=accept chain=input comment="Allow SSTP" dst-port=443 protocol=tcp
add action=accept chain=input comment=\
    "Accept all connections from admin networks" src-address-list=admin_nets
add action=drop chain=input comment=\
    "Drop all packets which are not destined to routers IP addresses" \
    dst-address-type=!local
add action=drop chain=input comment=\
    "Drop all packets which does not have unicast source IP address" \
    src-address-type=!unicast
add action=accept chain=input comment="Accept rate-limited ICMP" limit=\
    1,5:packet protocol=icmp
add action=drop chain=input comment="Drop everything else"
add action=drop chain=forward comment="Drop invalid packets" connection-state=\
    invalid
add action=accept chain=forward comment="Accept ipsec in" ipsec-policy=in,ipsec
add action=accept chain=forward comment="Accept ipsec out" ipsec-policy=\
    out,ipsec
add action=drop chain=forward comment=\
    "Drop all packets from internet which should not exist in public network" \
    in-interface-list=WAN ipsec-policy=in,none src-address-list=NotPublic
add action=fasttrack-connection chain=forward comment=\
    "Accept established and related packets (FastTrack)" connection-state=\
    established,related
add action=accept chain=forward comment=\
    "Accept established and related packets" connection-state=\
    established,related
add action=drop chain=forward comment=\
    "Drop new connections from internet which are not dst-natted" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN \
    ipsec-policy=in,none
/ip firewall nat
add action=src-nat chain=srcnat comment="srcnat to Internet (excluding ipsec)" \
    ipsec-policy=out,none out-interface-list=WAN to-addresses={branch_public_net}.31
/ip firewall raw
add action=notrack chain=prerouting dst-address-list=corp_nets \
    src-address-list=local_nets
add action=notrack chain=prerouting dst-address-list=local_nets \
    src-address-list=corp_nets
/ip ipsec identity
add peer=peer1
/ip ipsec policy
add comment=Corp dst-address=10.24.8.0/21 proposal=corp sa-dst-address=\
    {corp_public_net}.230 sa-src-address={branch_public_net}.31 src-address=192.168.1.0/24 \
    tunnel=yes
add comment=Corp dst-address=192.168.53.0/24 proposal=corp sa-dst-address=\
    {corp_public_net}.230 sa-src-address={branch_public_net}.31 src-address=192.168.1.0/24 \
    tunnel=yes
/ip route
add distance=1 gateway={branch_public_net}.1
I was hoping to setup a netwatch due to another problem where traffic occasionally stops passing even though PH1 and PH2 both show established. Disabling and enabling the policy fixes it for awhile. (If anyone can see anything that might cause that let me know.)
 
User avatar
Anumrak
Forum Guru
Forum Guru
Posts: 1051
Joined: Fri Jul 28, 2017 2:53 pm

Re: Ping IPSEC host from router

Tue Apr 23, 2019 1:59 pm

Hey. What about accept nat rule for your host in the tunnel before main src-nat rule? You are nating your requests into global IP address.
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Tue Apr 23, 2019 3:41 pm

What about accept nat rule for your host in the tunnel before main src-nat rule?
That would be one way to solve it; the other one, consistent with the approach already used, is to add an action=notrack dst-address-list=corp_nets rule also to chain=output of /ip firewall raw.

The explanation is that packets sent by Mikrotik itself do not pass through the prerouting path, see the packet flow diagram.

For the record, use of action=notrack rules makes it impossible to use stateful firewall to control traffic matching these rules, so in some scenarios, the approach using action=accept exceptions from action=src-nat or action=masquerade may have to be used instead.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
Anumrak
Forum Guru
Forum Guru
Posts: 1051
Joined: Fri Jul 28, 2017 2:53 pm

Re: Ping IPSEC host from router

Tue Apr 23, 2019 3:46 pm

What about accept nat rule for your host in the tunnel before main src-nat rule?
That would be one way to solve it; the other one, consistent with the approach already used, is to add an action=notrack dst-address-list=corp_nets rule also to chain=output of /ip firewall raw.

The explanation is that packets sent by Mikrotik itself do not pass through the prerouting path, see the packet flow diagram.

For the record, use of action=notrack rules makes it impossible to use stateful firewall to control traffic matching these rules, so in some scenarios, the approach using action=accept exceptions from action=src-nat or action=masquerade may have to be used instead.
Say no to control absent.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Tue Apr 23, 2019 5:52 pm

Thank you. Unfortunately it still isn't working. I have tried:
/ip firewall nat
add action=accept chain=srcnat dst-address=10.25.8.0/21
add action=src-nat chain=srcnat comment="srcnat to Internet (excluding ipsec)
    ipsec-policy=out,none out-interface-list=WAN to-addresses={branch_public_net}.31
I have also tried:
/ip firewall raw
add action=notrack chain=prerouting dst-address-list=corp_nets src-address-list=\
    local_nets
add action=notrack chain=prerouting dst-address-list=local_nets src-address-list=\
    corp_nets
add action=notrack chain=output dst-address-list=corp_nets
Either or both make no difference. It looks like other people with this config can ping successfully if they add an inside src-address to the ping command. That doesn't even work for me.
For the record I'm not crazy about notrack myself, but once a lot of traffic is crossing this policy it seems like the best way to keep cpu utilization down.
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Tue Apr 23, 2019 7:14 pm

It looks like other people with this config can ping successfully if they add an inside src-address to the ping command.
Normally you don't even need to set src-address for ping if you add a dedicated route for those destinations with pref-src set to the private address.

For the record I'm not crazy about notrack myself, but once a lot of traffic is crossing this policy it seems like the best way to keep cpu utilization down.
What amount of traffic do you have that a 1100AHx4 doesn't handle it, especially as you have chosen encryption and authentication algorithms supported in hardware?

As for why it doesn't work for you - normally, action=accept connection-state=established,related is the first rule in both chain=input and chain=forward of /ip firewall filter. Not in your case - you've put action=drop chain=input in-interface-list=WAN src-address-list=NotPublic before it, so although the ping responses coming back belong to an established connection and match the action=notrack rule in chain=prerouting of /ip firewall raw, this rule matches them first and drops them. Packets decrypted from IPsec transport ones inherit the in-interface attribute from them, and the source address definitely matches src-address-list=NotPublic. In your case, changing the order of the rules wouldn't help either as you use the notrack approach but the action=accept connection-state=established,related rule doesn't read action=accept connection-state=established,related,untracked. So you'll have to tidy up your firewall in general (and maybe reduce the CPU load by pushing action=accept connection-state=established,related,untracked to the beginning of both chains), but to see it working quickly, you should copy the rule action=accept chain=forward ipsec-policy=in,ipsec also to chain=input before the action=drop chain=input in-interface-list=WAN src-address-list=NotPublic one.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Tue Apr 23, 2019 8:49 pm

Setting the route is the very first thing I tried. When I decided there were other problems I started using src-address for troubleshooting. Having tried it again I find that my pings show up on the packet sniffer with a source address of the public address unless I specifically set src-address in the ping command. Perhaps I'm doing it wrong: add distance=1 dst-address=10.24.8.0/21 gateway="bridge1(LAN)" pref-src=192.168.1.1

Honestly this is my only 1100AHx4. I suspect I will never run into CPU issues with it. I'm just used to trying to be as efficient as possible.

Between my last reply and yours I noticed the drop non-public on input and added ipsec-policy=in,none to it. That didn't help so I disabled that drop rule entirely, still without success. Now I have also moved the drop non-public input rule below the established and related rule for good measure. I also caught my typo on the srcnat accept rule dst-address and changed it to use the corp_nets list. (It was still within the network so shouldn't have mattered.)

I am beginning to wonder if the problem could be at the other side; I don't have control of that and can't easily get packet traces. Since I can't follow a packet through the ipsec policy (that I know of) I have no good way of knowing if my ping is making it out but being blocked at the other end. I can't imagine how they would be doing that without blocking the pings I'm sending from a workstation at the branch. Those pings come back just fine.

Also in the meantime my tunnel has been passing traffic for three days without incident, so that problem may be fixed. I would still like to watch it from the router and not a workstation, though.
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Tue Apr 23, 2019 9:18 pm

Perhaps I'm doing it wrong: add distance=1 dst-address=10.24.8.0/21 gateway="bridge1(LAN)" pref-src=192.168.1.1
Nothing wrong about it. The value of gateway is actually not important and the rest is correct.

I am beginning to wonder if the problem could be at the other side
This was what I'd thought until I've spotted that killer rule. So back to that idea.

Since I can't follow a packet through the ipsec policy (that I know of) I have no good way of knowing if my ping is making it out but being blocked at the other end.
Are the policies on the remote end configured statically or you can add a dedicated policy for src-address=192.168.1.1/32 before one of those for src-address=192.168.1.0/24 and the remote end will accept such change? This way you'd get another pair of SAs only for Mikrotik's own traffic on which you could observe the traffic counters and conclude in which direction the problem is.

I can't imagine how they would be doing that without blocking the pings I'm sending from a workstation at the branch. Those pings come back just fine.
A selective firewall rule dropping packets from or to 192.168.1.1, why not.

So if you want to experiment a little bit more, you can transmutate your action=notrack rules in /ip firewall raw into action=accept rules in /ip firewall nat to allow connection tracking of the IPsec-encapsulated traffic and stil exclude it from src-nat'ing, and then add before them a rule like chain=srcnat action=src-nat dst-address=10.24.8.0/21 src-address=192.168.1.1 to-addresses=192.168.1.something_else to make pings from your Mikrotik look like pings from the device from which you know them to work.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Tue Apr 23, 2019 10:14 pm

This was what I'd thought until I've spotted that killer rule. So back to that idea.
Sadly that wasn't it, hence my wonderment.
Are the policies on the remote end configured statically or you can add a dedicated policy for src-address=192.168.1.1/32 before one of those for src-address=192.168.1.0/24 and the remote end will accept such change? This way you'd get another pair of SAs only for Mikrotik's own traffic on which you could observe the traffic counters and conclude in which direction the problem is.
I thought of that, but the other end is static and getting that policy added on their side is politically difficult.
A selective firewall rule dropping packets from or to 192.168.1.1, why not.
They don't even know my router's private address, so that rule is unlikely to exist.
So if you want to experiment a little bit more, you can transmutate your action=notrack rules in /ip firewall raw into action=accept rules in /ip firewall nat to allow connection tracking of the IPsec-encapsulated traffic and stil exclude it from src-nat'ing, and then add before them a rule like chain=srcnat action=src-nat dst-address=10.24.8.0/21 src-address=192.168.1.1 to-addresses=192.168.1.something_else to make pings from your Mikrotik look like pings from the device from which you know them to work.
I was halfway through doing this when your reply came. It didn't help. I've added another private address to no avail. However, now my packet traces always show the ping originating from the public address, even with src-address set on the ping. Very frustrating. I'm not sure where along the way I managed to break that.
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Tue Apr 23, 2019 10:30 pm

now my packet traces always show the ping originating from the public address, even with src-address set on the ping
Wait a bit, where do you take those traces? Because if you can see the ping requests to leave with a public address as source, it is clear that none of the policies could grab them. And unless your route with the private address set as pref-src is inactive because its gateway interface is down, the src-nat or masquerade must have beaten the pref-src setting. As you say that even the src-address parameter of ping doesn't win, it must be a NAT issue.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Wed Apr 24, 2019 4:45 am

I'm using the packet sniffer on the Mikrotik. Several hours ago the traces reflected the src-address specified in the ping command, although they always appeared at the WAN interface. Now they always show from the public IP. Outgoing pings from other local hosts to hosts across the vpn never show up at the WAN interface, but the return pings do. This confirms for me that the router pings are never being picked up by the policy.
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Wed Apr 24, 2019 9:24 am

This confirms for me that the router pings are never being picked up by the policy.
It doesn't. On ingress, the sniffer can see both the IPsec transport packet and the payload decapsulated and decrypted from it, but on egress it can only see the IPsec transport packet, not the plaintext one which has been encrypted and encapsulated into it.

Besides, the ping responses you can see do not appear out of blue, they are responses to the requests which did get there but you haven't seen them due to the above.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Wed Apr 24, 2019 3:39 pm

On ingress, the sniffer can see both the IPsec transport packet and the payload decapsulated and decrypted from it, but on egress it can only see the IPsec transport packet, not the plaintext one which has been encrypted and encapsulated into it.
Exactly my point. As you said before, since I can see the outgoing plain text ping at the WAN interface it must never enter the policy. Too bad there isn't a way to expose that moment of encapsulation as though it were an interface, but in this case the presence of one indicates the absence of the other. I'm not sure why I can't get the policy to pick up internal pings. I guess I'll have to rely on another host to monitor the tunnel. Fortunately it appears to be quite stable now. Thanks for your help.
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Wed Apr 24, 2019 3:53 pm

Exactly my point.
Sorry, I've misread the part about "other hosts".
I'm not sure why I can't get the policy to pick up internal pings.
Because the source address of the pings is not set to the private one. Post the whole export of the current configuration after all those changes (see my signature for anonymization hints), it is no rocket science, there must be some small mistake.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Wed Apr 24, 2019 6:18 pm

Because the source address of the pings is not set to the private one.
All of my pings throughout this process have included src-address={a private address}. (I have tried multiple private addresses.) My understanding is this should work without any tweaking of NAT rules or routes. Since it isn't working either way I have disabled experimental NAT rules.
# apr/24/2019 09:10:51 by RouterOS 6.44.2
# software id = UFWD-1G10
#
# model = RouterBOARD 1100x4
/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
set [ find default-name=ether2 ] speed=100Mbps
set [ find default-name=ether3 ] speed=100Mbps
set [ find default-name=ether4 ] speed=100Mbps
set [ find default-name=ether5 ] speed=100Mbps
set [ find default-name=ether6 ] speed=100Mbps
set [ find default-name=ether7 ] speed=100Mbps
set [ find default-name=ether8 ] speed=100Mbps
set [ find default-name=ether9 ] speed=100Mbps
set [ find default-name=ether10 ] speed=100Mbps
set [ find default-name=ether11 ] speed=100Mbps
set [ find default-name=ether12 ] speed=100Mbps
set [ find default-name=ether13 ] name="ether13(WAN)" speed=100Mbps
/interface bridge
add fast-forward=no name="bridge1(LAN)"
/interface bridge port
add bridge="bridge1(LAN)" interface=ether2
add bridge="bridge1(LAN)" interface=ether3
add bridge="bridge1(LAN)" interface=ether4
add bridge="bridge1(LAN)" interface=ether5
add bridge="bridge1(LAN)" interface=ether6
add bridge="bridge1(LAN)" interface=ether7
add bridge="bridge1(LAN)" interface=ether8
add bridge="bridge1(LAN)" interface=ether9
add bridge="bridge1(LAN)" interface=ether10
add bridge="bridge1(LAN)" interface=ether11
add bridge="bridge1(LAN)" interface=ether12
add bridge="bridge1(LAN)" interface=ether1
/interface list
add name=WAN
add name=LAN
/interface list member
add interface="bridge1(LAN)" list=LAN
add interface="ether13(WAN)" list=WAN
/interface sstp-server server
set authentication=mschap2 certificate=server-certificate default-profile=\
    sstp-profile enabled=yes force-aes=yes pfs=yes
/ip address
add address={branch_public_net}.31/24 interface="ether13(WAN)" network={branch_public_net}.0
add address=192.168.1.1/24 interface="bridge1(LAN)" network=192.168.1.0
add address=192.168.1.17/24 interface="bridge1(LAN)" network=192.168.1.0
/ip dhcp-server
add address-pool=dhcp authoritative=after-2sec-delay disabled=no interface=\
    "bridge1(LAN)" lease-time=1h name=dhcp1
/ip dhcp-server config
set store-leases-disk=never
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=192.168.1.12,192.168.1.14 gateway=192.168.1.1 \
    netmask=24
/ip pool
add name=vpn-pool ranges=192.168.11.201-192.168.11.220
add name=dhcp ranges=192.168.1.101-192.168.1.200
/ip dns
set servers=8.8.8.8
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www address=192.168.1.0/24,192.168.11.0/24
set ssh address=192.168.1.0/24,192.168.11.0/24
set www-ssl certificate=server-certificate disabled=no port=8443
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set allow-none-crypto=yes
/ip ipsec policy
add comment=Corp dst-address=10.24.8.0/21 proposal=corp sa-dst-address=\
    {corp_public_net}.230 sa-src-address={branch_public_net}.31 src-address=192.168.1.0/24 tunnel=yes
add comment=Corp disabled=yes dst-address=192.168.53.0/24 proposal=corp \
    sa-dst-address={corp_public_net}.230 sa-src-address={branch_public_net}.31 src-address=\
    192.168.1.0/24 tunnel=yes
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc
add enc-algorithms=aes-256-cbc lifetime=1h name=corp pfs-group=none
/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256
add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 lifetime=8h \
    name=profile_1 nat-traversal=no
/ip ipsec peer
add address={corp_public_net}.230/32 comment=Corp name=peer1 profile=profile_1
/ip ipsec identity
add peer=peer1
/ip route
add distance=2 gateway={branch_public_net}.1
add distance=1 dst-address=10.24.8.0/21 gateway="bridge1(LAN)" pref-src=192.168.1.1
/ip firewall address-list
add address=192.168.1.0/24 list=admin_nets
add address=192.168.11.0/24 list=admin_nets
add address={corp_public_net}.230 list=admin_nets
add address={corp_public_net}.230 list=corp
add address=10.24.8.0/21 list=corp_nets
add address=192.168.53.0/24 list=corp_nets
add address=192.168.1.0/24 list=local_nets
add address=0.0.0.0/8 comment=RFC6890 list=NotPublic
add address=10.0.0.0/8 comment=RFC6890 list=NotPublic
add address=100.64.0.0/10 comment=RFC6890 list=NotPublic
add address=127.0.0.0/8 comment=RFC6890 list=NotPublic
add address=169.254.0.0/16 comment=RFC6890 list=NotPublic
add address=172.16.0.0/12 comment=RFC6890 list=NotPublic
add address=192.0.0.0/24 comment=RFC6890 list=NotPublic
add address=192.0.2.0/24 comment=RFC6890 list=NotPublic
add address=192.168.0.0/16 comment=RFC6890 list=NotPublic
add address=192.88.99.0/24 comment=RFC3068 list=NotPublic
add address=198.18.0.0/15 comment=RFC6890 list=NotPublic
add address=198.51.100.0/24 comment=RFC6890 list=NotPublic
add address=203.0.113.0/24 comment=RFC6890 list=NotPublic
add address=224.0.0.0/4 comment=RFC4601 list=NotPublic
add address=240.0.0.0/4 comment=RFC6890 list=NotPublic
/ip firewall filter
add action=accept chain=input comment="Accept established and related packets" \
    connection-state=established,related,untracked
add action=drop chain=input comment="Drop invalid packets" connection-state=invalid
add action=drop chain=input comment="Drop all packets from public internet which sho\
    uld not exist in public network" in-interface-list=WAN ipsec-policy=in,none \
    src-address-list=NotPublic
add chain=input comment="Accept all connections from local network" \
    in-interface-list=LAN
add action=accept chain=input comment="Allow remote webfig" disabled=yes dst-port=\
    8443 protocol=tcp
add action=accept chain=input comment="Accept IPSEC udp 500" dst-port=500 protocol=\
    udp
add action=accept chain=input comment="Accept IPSEC udp 4500" dst-port=4500 \
    protocol=udp
add action=accept chain=input comment="Allow SSTP" dst-port=443 protocol=tcp
add action=accept chain=input comment="Accept all connections from admin networks" \
    src-address-list=admin_nets
add action=drop chain=input comment=\
    "Drop all packets which are not destined to routers IP addresses" \
    dst-address-type=!local
add action=drop chain=input comment=\
    "Drop all packets which does not have unicast source IP address" \
    src-address-type=!unicast
add action=accept chain=input comment="Accept rate-limited ICMP" limit=1,5:packet \
    protocol=icmp
add action=drop chain=input comment="Drop everything else"
add action=accept chain=forward comment="Accept ipsec in" disabled=yes \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="Accept ipsec out" disabled=yes \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=\
    "Accept established and related packets (FastTrack)" connection-state=\
    established,related ipsec-policy=in,none
add action=accept chain=forward comment="Accept established and related packets" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="Drop invalid packets" connection-state=\
    invalid
add action=drop chain=forward comment=\
    "Drop all packets from internet which should not exist in public network" \
    in-interface-list=WAN ipsec-policy=in,none src-address-list=NotPublic
add action=drop chain=forward comment=\
    "Drop new connections from internet which are not dst-natted" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN \
    ipsec-policy=in,none
/ip firewall nat
add action=src-nat chain=srcnat disabled=yes dst-address-list=corp_nets \
    src-address-type=local to-addresses=192.168.1.17
add action=accept chain=srcnat dst-address-list=corp_nets src-address-type=local \
    to-addresses=192.168.1.1
add action=src-nat chain=srcnat comment="srcnat to Internet (excluding ipsec)" \
    ipsec-policy=out,none out-interface-list=WAN to-addresses={branch_public_net}.31
/ip firewall raw
add action=notrack chain=prerouting disabled=yes dst-address-list=corp_nets \
    src-address-list=local_nets
add action=notrack chain=prerouting disabled=yes dst-address-list=local_nets \
    src-address-list=corp_nets
add action=notrack chain=output disabled=yes dst-address-list=corp_nets
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Wed Apr 24, 2019 8:24 pm

Actually the hierarchy of source address assignment for packets originated by Mikrotik itself is the following:
  • the IP address of the interface associated to the gateway of the route used (which is either the interface itself or the interface in the same subnet like the gateway IP, leaving recursive next-hop search aside),
  • the above can be superseded by pref-src of the route,
  • the above can be superseded by specifying a src-address for ping and several other commands (ssh, telnet, ...)
However, regardless what is the result of the above, NAT rules supersede all of that because they are processed later. And ipsec policies' traffic selectors act after the NAT.

So when we have a look at your currently enabled NAT rules,

action=accept chain=srcnat dst-address-list=corp_nets src-address-type=local to-addresses=192.168.1.1

action=src-nat chain=srcnat comment="srcnat to Internet (excluding ipsec)" ipsec-policy=out,none out-interface-list=WAN to-addresses={branch_public_net}.31
:

  • the first one of them should act only on locally originated packets (from any of the local addresses) due to src-address-type=local (which, in contrary to popular belief, does not match to all addresses in "connected subnets", only to Mikrotik's own addresses) and leave the source address of these packets unchanged. BTW, to-addresses has no meaning for action=accept so I wonder why export even shows it. So maybe unset that parameter just for the case that it would eventually cause the whole rule to be ignored
  • the second one should only act on packets which the regular routing sends out via WAN interface (and here, I have never understood the role of ipsec-policy=out,none because I've never seen this match condition to actually work - I've only seen it working for ingress packets where you can distinguish between the decapsulated and decrypted ones (in,ipsec) and the rest (in,none).
So none of these NAT rules should do any harm if the route, address-list, and interface-list are set properly. Let's check that:
  • your exceptional route's destination is 10.24.8.0/21 and the pref-src is 192.168.1.1 which is one of your local IP addresses,
  • there is no exceptional route with dst-address=192.168.53.0/24,
  • the only member of /interface list name=WAN is ether13 which is the interface used by the default route, so the exceptional route prevents this interface from being used for packets towards 10.24.8.0/21, but not from being used for packets towards 192.168.53.0/24
  • the /ip firewall address-list name=corp_nets contains both 10.24.8.0/21 and 192.168.53.0/24
So I can see just a few possible reasons why it doesn't work as expected:
  • you ping an address from 192.168.53.0/24 and the chain=srcnat action=accept rule fails to match and accept the packet because it is confused by the redundant to-addresses parameter (what does /ip firewall nat print say about that?),
  • 6.44.2 has some mental problem with use of a bridge interface as a gateway of a route so the exceptional route is inactive (what does /ip route print say about that?), so the above scenario applies even if you ping a target from 10.24.8.0/21 (but it still requires that the action=accept rule was broken!),
  • something is simply broken in 6.44.2 and one of the stages of packet handling as outlined above does not work as expected
.

You can reset the packet counters in NAT and see whether the action=accept rule counts when you ping: ip firewall nat reset-counters-all, then /ip firewall nat print stats (should show 0 matches on the action=accept) rule, then a single run of ping, then /ip firewall nat print stats again and you should see 1 packet there (only the initial packet of each connection goes through the /ip firewall nat table, the remaining packets of the same connection are handled by connection tracking silently).

Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Thu Apr 25, 2019 6:24 pm

BTW, to-addresses has no meaning for action=accept so I wonder why export even shows it. So maybe unset that parameter just for the case that it would eventually cause the whole rule to be ignored
I wondered that myself. It's an artifact of changing the action from src-nat to accept. It's now unset.
I have never understood the role of ipsec-policy=out,none
Having studied the diagrams more thoroughly I question its existence as well. There would need to be an additional decision point to mark those packets. (Which would certainly solve a lot of problems.)
you ping an address from 192.168.53.0/24
192.168.53.0/24 was transitional at the corp office and is now disabled. I've never tried pinging one of those.
6.44.2 has some mental problem with use of a bridge interface as a gateway of a route
The dynamic route to the 192.168.1.0/24 network specifies the bridge as the gateway. But just to be sure I changed mine to ether4, with no change in results.

I tried watching stats before. Tried again after unsetting the to-address. Stays at 0. (Although it has occasionally caught something because it was not 0 when I started this time. In fact during the few minutes I spent typing this it did catch 1.)
 
sindy
Forum Guru
Forum Guru
Posts: 3895
Joined: Mon Dec 04, 2017 9:19 pm

Re: Ping IPSEC host from router

Thu Apr 25, 2019 7:05 pm

The dynamic route to the 192.168.1.0/24 network specifies the bridge as the gateway. But just to be sure I changed mine to ether4, with no change in results.
What matters is whether the print shows the route as inactive or not (it should be shown as Inactive with gateway=ether4 because ether4 is a member port of bridge and as such it should not be applicable as a gateway because it is invisible for the IP stack).

I tried watching stats before. Tried again after unsetting the to-address. Stays at 0. (Although it has occasionally caught something because it was not 0 when I started this time. In fact during the few minutes I spent typing this it did catch 1.)
Hm. That might mean that evaluation of one of the match conditions used is broken in this ROS version. So try replacing src-address-type=local by e.g. src-address=192.168.1.0/24, as the other conditions cannot be easily substituted. Or disable this rule completely and add dst-address-list=!corp_nets to the action=src-nat one, and put a chain=srcnat action=log rule after the action=src-nat to see in the log what is the source address and chosen output interface of packets which escape it.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Fri Apr 26, 2019 5:12 am

What matters is whether the print shows the route as inactive or not (it should be shown as Inactive with gateway=ether4 because ether4 is a member port of bridge and as such it should not be applicable as a gateway because it is invisible for the IP stack).
ether4 shows active.
Hm. That might mean that evaluation of one of the match conditions used is broken in this ROS version. So try replacing src-address-type=local by e.g. src-address=192.168.1.0/24, as the other conditions cannot be easily substituted. Or disable this rule completely and add dst-address-list=!corp_nets to the action=src-nat one, and put a chain=srcnat action=log rule after the action=src-nat to see in the log what is the source address and chosen output interface of packets which escape it.
Well it's working, though I'm unsure why. I took local off the accept rule and left src-address blank, thinking that I don't really want to srcnat any traffic going to the corp_nets list, anyway. I have worked backward trying to recreate the problem, but I can't. I have to think I had a typo somewhere, unless deleting and recreating a rule fixed it somehow. My route is also working fine at the bridge interface.
Sorry for any time waste on this, but I do think my firewall is in better shape now. Thank you very much.
 
McSee
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Tue Feb 26, 2019 12:49 pm

Re: Ping IPSEC host from router

Fri Apr 26, 2019 6:15 pm

Guys, IPsec policy 'out, none' criterion works just fine for me in a NAT rule.
As well as 'out, ipsec' as can be seen in the screenshot below.
.
IPsec_noNAT.PNG
You do not have the required permissions to view the files attached to this post.
Last edited by McSee on Fri Apr 26, 2019 8:04 pm, edited 1 time in total.
 
kwade
just joined
Topic Author
Posts: 10
Joined: Tue Apr 12, 2016 5:21 am

Re: Ping IPSEC host from router

Fri Apr 26, 2019 6:25 pm

Guys, IPsec policy 'out, none' criterion works just fine for me in a NAT rule.
So it does. Even better.

Who is online

Users browsing this forum: No registered users and 107 guests