MikroTik to Firebox BOVPN cannot route local traffic
Hi
I have BOVPN connection between MikroTik 3011 and T70 which works fine. Unfortunately with BOVPN On I cannot send/receive traffic between MikroTik local addresses and MikroTik itself. Without BOVPN everything works as expected. Any ideas?
0
Sign In to comment.
Comments
Please give an example of the IP addrs involved when you cannot send/receive traffic between MikroTik local addresses and MikroTik itself.
If the IP addrs are from the same subnet, then I would expect this to work.
If you have a default (zero) route BOVPN set up, then all packets not on the locally defined subnets will get routed down the BOVPN.
This is the case
I have on MikroTik side
172.26.5.1 GW:172.26.5.100
172.27.5.1 GW: 172.27.5.100
On FireBox side
172.16.5.1 GW: 172.16.5.100
I can reach from 172.16.5.1 to 172.26.5.1 and vice versa but cannot reach
172.27.5.1 from 172.26.5.1
What are the subnet masks involved on the BOVPN settings?
/24?
172.26.5.0/24 <-> 172.16.5.0/24
172.27.5.0/24 <-> 172.16.5.0/24
I’m not sure if I got you right but I have
Any IPv4 bidirectional 172.26.5.9/24.
Same with 172.27.5.0/24
Then no idea why this is happening.
Seems like a MikroTik routing issue.
Are there MikroTik boards on which you can ask questions?
That’s my next step then.
Thank you!
On the second thought -I have old XTM without subscription-will It help if I replace Mikrotik with it?
What model?
What Fireware version?
I would certainly expect the routing to work as expected on the old firewall.
Should work
Well, I installed XTM 33 but cannot get it to work. From T70 side I get error
“ Error Messages for Gateway Endpoint #1(name "gateway-BF")
Feb 04 18:28:13 2021 ERROR 0x02030015 Message retry timeout. Check the connection between local and remote gateway endpoints.”
Both endpoints are available. Additional log
158>Feb 4 18:28:00 iked[2039]: recv WGAPI_EVENT_DHCP_FILE_CHANGE notification
<158>Feb 4 18:28:00 iked[2039]: Generated hash for /etc/resolv.conf of size 70
<158>Feb 4 18:28:01 iked[2039]: (185.x.x.x<->94.x.x.x)Resending phase-1 message to 94.x.x.x. Gateway-Endpoint:gateway-BF p1saId:0x0
<158>Feb 4 18:28:05 iked[2039]: (185.x.x.x<->94.x.x.x)Resending phase-1 message to 94.x.x.x. Gateway-Endpoint:gateway-BF p1saId:0x0
<158>Feb 4 18:28:09 iked[2039]: (185.x.x.x<->94.x.x.x)Resending phase-1 message to 94.x.x.x. Gateway-Endpoint:gateway-BF p1saId:0x0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)alwaysUpTimerCb trigger autoStart for ikePcy(gateway-BF) ipsecPcy(tunnel-BF)
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)AUTOSTART: RECV ipecPcy(tunnel-BF), ikePcy(gateway-BF), ifIndex(2), tunnel_src=185.x.x.x, tunnel_dst=94.x.x.x
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)do the ACQUIRE action for the tunnel route [src:192.168.0.0/24 <-> dst:192.168.20.0/24], ike_ver=1, peer_udp_port=0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)(NATT)IkeFindIsakmpSABySPD: Matched IP and peer_udp_port=0 p1saId=0 : pIsakmpSA p1saID=0 DestPort=0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)(NATT)IkeFindIsakmpSABySPD: Matched IP and peer_udp_port=0 p1saId=0 : pIsakmpSA p1saID=0 DestPort=0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)StartNegotiation: P1 negotiation is still going on... Increment Pending P2SA counter 1 (Gateway-Endpoint gateway-BF)
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)(StartNego) rasUserCapacity 60 count 2
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)(StartNego) maxPendingP2SARequest 128 current 1
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)do the ACQUIRE action for the tunnel route [src:172.16.5.0/24 <-> dst:172.26.5.0/24], ike_ver=1, peer_udp_port=0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)(NATT)IkeFindIsakmpSABySPD: Matched IP and peer_udp_port=0 p1saId=0 : pIsakmpSA p1saID=0 DestPort=0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)(NATT)IkeFindIsakmpSABySPD: Matched IP and peer_udp_port=0 p1saId=0 : pIsakmpSA p1saID=0 DestPort=0
<158>Feb 4 18:28:11 iked[2039]: (185.x.x.x<->94.x.x.x)StartNegotiation: P1 negotiation is still going on... Increment Pending P2SA counter 2 (Gateway-Endpoint gateway-BF)
Interesting that on XTM VPN Ststistics tab do not show any tunnel regardless I have defined a bunch of them.
Any help?
***Edited by WatchGuard to remove IP addresses from logs.
It looks to be using NAT (NATT) - what is in front of either end of the firewalls which is doing NAT ?
What do you see on the other firewall's logs related to IPSec?
It is direct firebox to ISP connection
I do not see at all any attempt of connection from IP of T70 to XTM
When I filter by IKED I get:
configuration setting has been processed successfully id="0201-2335"
2021-02-04 20:06:00 iked Starts processing a configuration setting id="0201-2334"
2021-02-04 20:06:00 iked Before G.C. addrObjCnt=8, natObjCnt=1 ikeActionCnt=1, ikePolicyCnt=1, ikePolicyGroupCnt=1, ipsecProposalCnt=6, ipsecPolicyCnt=1, ipsecRouteObjCnt=0
2021-02-04 20:06:00 iked ike_config_garbage_collect: process address group list
2021-02-04 20:06:00 iked ike_config_garbage_collect: process NAT list
2021-02-04 20:06:00 iked ike_config_garbage_collect: process RAS user group list - updates
2021-02-04 20:06:00 iked ras_handle_updated_user_groups: RAS User group: PPTP-Users flags:0x00000000
2021-02-04 20:06:00 iked ike_config_garbage_collect: process IKE action list
2021-02-04 20:06:00 iked ike_config_garbage_collect: process IKE Policy list
2021-02-04 20:06:00 iked ike_config_garbage_collect: IKE Pcy: gateway-BF flags: 0
2021-02-04 20:06:00 iked ike_config_garbage_collect: IKE Pcy Grp: gateway-BF flags: 0
2021-02-04 20:06:00 iked ike_config_garbage_collect: process IPSEC Proposal list
2021-02-04 20:06:00 iked ike_config_garbage_collect: process IPSEC Policy list
2021-02-04 20:06:00 iked ike_config_garbage_collect: IPSEC Pcy: tunnel-BF flags: 0
2021-02-04 20:06:00 iked ike_config_garbage_collect: process RAS user group list - delete
2021-02-04 20:06:00 iked ras_handle_deleted_user_groups: RAS User group: PPTP-Users flags:0x00000000 usage-count:1
2021-02-04 20:06:00 iked ike_config_garbage_collect: process IPSec route GC list
2021-02-04 20:06:00 iked After G.C. addrObjCnt=8, natObjCnt=1 ikeActionCnt=1, ikePolicyCnt=1, ikePolicyGroupCnt=1, ipsecProposalCnt=6, ipsecPolicyCnt=1, ipsecRouteObjCnt=0
2021-02-04 20:06:00 iked A configuration setting has been processed successfully id="0201-2335"
2021-02-04 20:06:00 iked ******** RECV message on fd_server(7) ********
2021-02-04 20:06:00 iked recv RECONFIG_EVENT notification, need to ignore it
2021-02-04 20:06:06 iked ******** RECV message on fd_server(7) ********
2021-02-04 20:06:06 iked recv CMD XPATH(/ping), need to process it
2021-02-04 20:06:36 iked ******** RECV message on fd_server(7) ********
Is any access from the XTM to the Internet working?
If not, reboot the ISP device at that end and try again.
Also, there is a real Feature Key on the XTM box, correct?
If not, then BOVPNs won't work/
I will check tomorrow feature key, but my guess it is expired
Expired should not be an issue.
Expiration Column for Branch Office VPN Tunnels should show Never on the Feature Key in Policy Manager or the Web UI.
Is any access from the XTM to the Internet working?
If not, reboot the ISP device at that end and try again.
Yes, BOVPN expiration says never, internet is working, still no BOVPN. my guess something different between firmwares prevent phase 1 shared secret understanding.
You can turn on diagnostic logging for IKE which may show something to help:
In WSM Policy Manager: Setup -> Logging -> Diagnostic Log Level -> VPN -> IKE
In the Web UI: System -> Diagnostic Log
Set the slider to Information or higher
What I can see from site B (XTM) is sslvpn:Waiting for key/certificate generation to complete. From site A -message retry timeout.
I’m giving up at this point and go with mikrotik.