Hello,
I have ipsec vpn established between a cisco router and a mikrotik router.
But i am unable to ping host pcs connected.
Attached is the snapshot of the routes in the mikrotik.
Kindly assist
I have the same issue, but with a Fortigate.
Tunnel is established, but no ping.
Following has been tried:
Routes, NAT, Firewall + RAW.
Off the top of my head in order of commonality:
- Exclude VPN traffic from NAT translation.
- Ensure each VPN peer is the default gateway for its local network. If it isn’t, then the default gateway needs a route added that sets the next hop to the remote network as the VPN peer.
- Ensure each VPN peer’s firewall rules/ACLs allow the desired traffic.
- Ensure the VPN peer doesn’t have a route for the remote network pointing at an unintended next hop.
I have had my Hex S for 14 days, so relativily new to Mikrotik. But i like it.
Used several hours on the VPN topic, with out any luck.
The Tunnel is established, but can’t ping.
# may/16/2020 22:09:48 by RouterOS 6.46.6
# software id = RXZI-3K8X
#
# model = RB760iGS
# serial number = A36A0B953574
/interface bridge
add admin-mac=C4:AD:34:D8:DB:2D auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] comment=WAN
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec policy group
add name=Comits
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=Comits
/ip ipsec peer
add address=REMOTEWAN exchange-mode=ike2 local-address=MYWAN name=\
Comits port=500 profile=Comits
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-128-cbc lifetime=1d name=Comits \
pfs-group=modp2048
/ip pool
add name=dhcp ranges=192.168.15.10-192.168.15.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface detect-internet
set detect-interface-list=all
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.15.1/24 comment=defconf interface=ether2 network=\
192.168.15.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.15.0/24 comment=defconf gateway=192.168.15.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.15.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input dst-port=500,4500 protocol=udp
add action=accept chain=forward dst-address=192.168.5.0/24 src-address=\
192.168.15.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=\
192.168.15.0/24
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=accept chain=srcnat dst-address=192.168.5.0/24 src-address=\
192.168.15.0/24
add action=accept chain=srcnat dst-address=192.168.1.0/24 src-address=\
192.168.15.0/24
/ip ipsec identity
add peer=Comits policy-template-group=Comits
/ip ipsec policy
add dst-address=192.168.1.0/24 peer=Comits proposal=Comits sa-dst-address=\
94.137.134.194 sa-src-address=MYWAN src-address=192.168.15.0/24 \
tunnel=yes
add dst-address=192.168.5.0/24 peer=Comits proposal=Comits sa-dst-address=\
94.137.134.194 sa-src-address=MYWAN src-address=192.168.15.0/24 \
tunnel=yes
/ip route
add distance=1 dst-address=192.168.1.0/32 gateway=ether1
add distance=1 dst-address=192.168.5.0/32 gateway=ether1
/system clock
set time-zone-name=Europe/Copenhagen
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
If you use ipsec and need to access local resources, then set the Proxy-arp option for the Bridge interface.
/interface bridge
add arp=proxy-arp name=bridge1
Unlike routes, the rules in firewall (and multiple other configuration branches) are matched in sequential order, not by best match. Hence you have to move the two action=accept rules in chain=srcnat of /ip firewall nat before (above) the action=masquerade one.
Also the first two rules in chain=forward of /ip firewall filter should be redundant (not harmful), as the next two ones from the default configuration, action=accept ipsec-policy=(in|out),ipsec, should do their job of preventing packets handled by IPsec policies from reaching the action=fasttrack-connection rule.
This is only relevant when you assign to your VPN clients addresses which fit into your LAN subnets. That’s not the case here.
Done
Traffic is being registered, but stil no positiv ping result.
I know for 200% that the remote firewall is working correctly.
What do the installed SA show under IP->IPsec?
There should be two per each remote subnet. If both count packets and bytes while you ping, the issue is at the Mikrotik end; if only the one from Mikrotik to Fortigate counts, it is an issue with IPsec itself or the firewall at the Fortigate end.
Try to add a chain=input action=accept protocol=ipsec-esp rule to /ip firewall filter, as the very first one in chain=input - it is not the right final place for it but it is to check what the issue may be.
Since both devices have public IP addresses, they use ESP as transport protocol. The transport packets only come if they have any payload to carry, so there are three possible reasons why no ESP packets arrive as the installed SA table shows:
- the remote device doesn’t respond your pings or it doesn’t have a route to your subnet via the Fortigate box, hence the Fortigate gets nothing to send in the ESP
- something on the path between the Fortigate and the Mikrotik drops ESP
- something has changed in the firewall implementation on Mikrotik and the “accept established” rule doesn’t accept incoming ESP packets although the Mikrotik did send ones in the opposite direction
You have no rules in /interface bridge filter or /ip firewall raw, so the ESP packets really do not arrive to your WAN (I suppose you tried to ping before posting the screenshot).
To check that the Fortigate eventually does send the ESP packets but they do not arrive to Mikrotik, you may set the local-address of the peer representing the Fortigate to 192.168.15.1, and set up a dst-nat rule on the WAN, chain=dstnat action=dst-nat protocol=udp dst-port=500,4500 dst-address-type=local in-interface=ether1 to-addresses=192.168.15.1. Then, you’d have to disable the identity or peer for a while, remove the IPsec connection from the firewall using /ip firewall connection remove [find dst-address~“ip.of.the.fortigate” or src-address~“ip.of.the.fortigate”], and re-enable the identity or peer. If NAT-T support is enabled at Fortigate side, the tunnel will come up and the ESP will be sent encapsulated into UDP - the installed SA should show the addresses with port number (:4500) addresses.
If even this way the pings won’t start getting through, the issue is at the Fortigate end.
Eu estou com um problema semelhante.
A configuração da minha VPN entre Mikrotik e Fortigate. Tenho os Servidores e internet no lado da Fortigate a VPN está estabelecida e consigo pingar para as duas redes, mas não tenho acesso internet do lado do Mikrotik. O que estará em falta?
This fixed my issues of traffic not passing over the VPN, wasn’t mentioned in any other tutorials I’ve seen ether but they were based on older firmware and the location for various settings and quantity of tabs has changed since that info was put together under IPSec in Mikrotik. Even the step by step video tutorial that I copied in which he did test pings at the end and it worked for him didn’t work for me (again older firmware). Did the same and the connection came up but test pings wouldn’t pass until I added this. Thanks
I just configured a RB750gr3 with RouterOS v6.49.7 (stable), got the IPSEC established, but no traffic. I had to run this in order to get it to pass traffic and move the rule to the top of the list.
/ip firewall filter add chain=input action=accept protocol=ipsec-esp
But my old RB962 with RouterOS v6.49.1 (stable), I didn’t need to add this firewall rule to make it work. So something changed between .1 and .7 to make this behave different?
And even after adding this, I have traffic from the remote end (pfSense) to my mikrotik’s LAN over IPSEC, but not the other way around. Any ideas where I can start hunting this down?
Edit, I managed to solve this, my NAT rules were out of whack.
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN
The thing that changes is the default firewall rules that are applied at the moment you first power-up the device. These are made using the RouterOS version installed at that time.
Therefore it is always recommended to do this:
- powerup router and connect a local machine and the internet
- configure it as much as required to obtain internet
- do a RouterOS upgrade to the most recent version and upgrade Routerboard Firmware
- RESET CONFIG TO DEFAULT
- only now, start making the config you want to use (configure internet again as done above, and make other config you require)
Omitting the reset to default step leaves you with a potentially outdated and bad firewall config. That probably happened on your RB750Gr3.
I recommend to do it now, if required first to a /export file=config and download config.rsc so you have a overview of the config you made, but do not import it.
Ok, I actually did do a factory reset and then set it up from scratch (I messed it up so bad I thought I’d rather start from fresh - I saved the commands) that probably explains why the behavior on my RB750 is different to my RB962.
So what are the implications for this if I deploy a device and then send it out to a remote office? If I upgrade the firmware, I will end up with possibly inconsistent states?
The point is that a new RouterOS version will include better firewall rules that are better compatible with using IPsec, NAT and port forwarding (typical home or small business router use), but you never get these updates as your actual firewall rules because that only happens on “reset to defaults”.
When you remotely update a router it will keep the same firewall rules as it always had. When it was working (because you tweaked the firewall to get it working), it will remain working.
But for new setups, the improved firewall rules are certainly much easier to work with.
Then, as I have written before many times, I do not recommend using direct IPsec tunnels, I recommend setting up a GRE or IPIP tunnel with IPsec password, it will offer the same protection but it will be a transparent tunnel between your sites, that you can route traffic through as you wish. Much easier to get going.