11-02-2021 03:16 PM
Hi,
Couple of days ago I asked for help about VPN between Fortinet and Cisco 881 series router. I got the help (greatly appreciate it).Today I was doing some tests with the Fortinet engineer and then we found that there are still some problem.
I have configured a VPN tunnel between Fortinet device and a Cisco 881 device.
The phase1 and phase 2 came up and tunnel is up.
It was a requirement by Fortinet to make the configuration in Aggressive Mode.
The Cisco 881 will be configured on the office and shipped to remote users working from home. The user will just need to connect the Cisco 881 to his/her modem at home on port F4 which is the WAN port and then plug his Cisco phone on either Port0 or Port1 which does PoE and then plug the laptop in any other Port.
Phone should come up and at the same time the laptop will be connected to network as the Cisco 881 will be doing the hardware VPN.
Right now everything seems ok but cannot test as it is not in production but some basic routing seems not working.
I ping 8.8.8.8 from the Cisco router.
The phone is getting a correct ip address as well as the laptop
From Cisco 881 I can ping 8.8.8.8 and 10.21.64.4 as well as I can ping the phone which is 10.88.120.3 but CANNOT ping 10.88.120.4 which is the laptop.
NOW from laptop I can ping 8.8.8.8 and browse internet.
From laptop CANNOT ping 10.21.64.7 which is a test ip on Fortinet Lan .
I am attaching the sh run of Cisco 881 as well as a brief topology of the interconnection and sh ip route
At the end if this works I will need to add 2 subnets on on the Cisco 881 so that users will be able to access when connecting to VPN.
Any kind of help will be appreciated.
Thanks
Tazio
Solved! Go to Solution.
11-02-2021 03:30 PM - last edited on 11-25-2021 09:47 PM by Translator
Hello,
there is an IP address misconfiguration on your Vlan 1 interface:
ip dhcp pool INTERNAL
network 10.88.120.0 255.255.255.248
default-router 10.88.120.1
dns-server 8.8.8.8
!
interface Vlan1
ip address 10.88.120.2 255.255.255.248 <-- this needs to be 10.88.120.1
ip nat inside
11-06-2021 10:15 AM
Tazio
Thanks for the update. I am puzzled that the Fortinet engineer thought that an IP address on the tunnel was not important. The results when you did configure IP addresses on the tunnel interfaces show that it is indeed important.
The most important result is this "From Laptop I can ping 8.8.8.8 and 10.21.64.7" so the encrypted tunnel is working and the Lan to Lan communication is most important.
I can understand why this ping did not work "ping 10.21.64.7 source f4"
and the key to that result is this "Packet sent with a source address of 192.168.0.22" if the source address is 192.168.0.22 then Fortinet will attempt to send the response to that address. But how would Fortinet be able to reach that IP address?
I would think that the ping sourced from the tunnel interface should have worked. That output indicates that the source address was 192.168.42.10 and that should be a connected interface on the Fortinet. I believe that there must be something on the Fortinet side that prevents that ping from being successful. Do you know anything about how the Fortinet is configured? Your router is configured to implement the encrypted tunnel using the Virtual Tunnel Interface approach. One of the important aspects of VTI is that it does not use the traditional crypto map. I wonder if the Fortinet does use a traditional crypto map?
In VTI any traffic that goes through the tunnel is encrypted. So your ping request would go through the tunnel and be encrypted. But if Fortinet is using a crypto map it must specify the source and destination addresses of traffic to be encrypted. It is clear that Fortinet has specified addresses for Lan to Lan traffic which is being encrypted (and which does work). But if Fortinet did not specify tunnel to tunnel traffic in their crypto map then that traffic would not get encrypted and the ping would fail.
I believe that the Lan to Lan traffic working is the most important thing. I would suggest that testing with ping from tunnel or from WAN addresses is not important and that you not be concerned if it does not work.
11-07-2021 01:50 PM - last edited on 11-25-2021 10:20 PM by Translator
Hello
@Tazio4436 wrote:
interface FastEthernet4
ip address dhcp
ip nat outside
FastEthernet4 192.168.0.22
ip route 0.0.0.0 0.0.0.0 FastEthernet4 dhcp
interface Tunnel0
ip address 192.168.42.10 255.255.255.0
tunnel source FastEthernet4
tunnel destination 184.94.68.98
Looks like you are double natting (modem & cisco rtr) and on the tunnel source ip to reach the tunnel destination, however you have no static translation for <192.168.0.22,192.168.42.10> and neither are public routable so how are the tunnel interfaces ips able to reach each other?
Also what you dont want to do is allow the rtr to arp for everything it supposedly thinks is directed connected via tunnel0.
no ip nat inside source list 1 interface FastEthernet4 overload
no ip route 10.21.64.7 255.255.255.255 Tunnel0
no access-list 1
access-list 100 deny ip 10.88.120.0 0.0.0.7 host 10.21.64.7
access-list 100 permit ip 10.88.120.0 0.0.0.7 any
ip nat inside source list 100 interface FastEthernet4
ip route 10.21.64.7 255.255.255.255 Tunnel0 x.x.x.x <tunnel nexthop>
Then you still have to sort out how 192.168.42.10 (which is sat behind modem 192.168.0.22) is going to be reached from the 184.94.68.98,
Do you have admin access to this modem?
Possible options - either
11-02-2021 03:30 PM - last edited on 11-25-2021 09:47 PM by Translator
Hello,
there is an IP address misconfiguration on your Vlan 1 interface:
ip dhcp pool INTERNAL
network 10.88.120.0 255.255.255.248
default-router 10.88.120.1
dns-server 8.8.8.8
!
interface Vlan1
ip address 10.88.120.2 255.255.255.248 <-- this needs to be 10.88.120.1
ip nat inside
11-02-2021 04:02 PM
11-03-2021 12:27 AM - last edited on 11-25-2021 09:49 PM by Translator
Hello,
your tunnel 0 interface is set to 'ip address dhcp', what IP address does it get, and where does the IP address come from ?
Also, make sure that aggressive mode is actually working on both ends (toggle the lines marked in bold to check if enabling and disabling aggressive mode makes a difference:
hostname CISCO-881_01
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
!
no aaa new-model
clock timezone EST -5 0
clock summer-time DST recurring
!
no ip dhcp conflict logging
ip dhcp excluded-address 10.88.120.0 10.88.120.2
!
ip dhcp pool INTERNAL
network 10.88.120.0 255.255.255.248
default-router 10.88.120.1
dns-server 8.8.8.8
!
ip domain name aclighting.com
ip name-server 8.8.8.8
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
crypto isakmp policy 1
encr aes 256
hash sha384
authentication pre-share
group 21
lifetime 28800
crypto isakmp key XXXXXX address A.A.A.A
!
crypto isakmp peer address A.A.A.A
set aggressive-mode password XXXXXXX
set aggressive-mode client-endpoint fqdn CISCO-881_01
!
crypto ipsec transform-set TSET esp-aes 256 esp-sha384-hmac
mode tunnel
!
crypto ipsec profile IPSEC-PROFILE
set transform-set TSET
!
--> crypto isakmp aggressive-mode disable
--> no crypto isakmp aggressive-mode disable
!
interface Tunnel0
ip address dhcp
tunnel source FastEthernet4
tunnel mode ipsec ipv4
tunnel destination A.A.A.A
tunnel protection ipsec profile IPSEC-PROFILE
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
no ip address
!
interface FastEthernet4
ip address dhcp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
!
interface Vlan1
ip address 10.88.120.1 255.255.255.248
ip nat inside
ip virtual-reassembly in
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip nat inside source list 1 interface FastEthernet4 overload
ip route 10.21.64.7 255.255.255.255 Tunnel0
ip route 0.0.0.0 0.0.0.0 FastEthernet4 dhcp
!
access-list 1 permit 10.88.120.0 0.0.0.7
!
control-plane
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
line con 0
no modem enable
line aux 0
line vty 0 4
login
transport input none
!
scheduler allocate 20000 1000
!
end
11-03-2021 05:52 AM - last edited on 11-25-2021 09:53 PM by Translator
Hi ,
It does not get any ip add.Please see below.
CISCO-881_01# sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0 unassigned YES unset up up
FastEthernet1 unassigned YES unset up down
FastEthernet2 unassigned YES unset up down
FastEthernet3 unassigned YES unset up up
FastEthernet4 192.168.0.33 YES DHCP up up
NVI0 unassigned YES unset administratively down down
Tunnel0 unassigned YES DHCP up up<=============
Vlan1 10.88.120.1 YES NVRAM up up
I tried to configure ip address manually. I tried on from the modem and second i tried one from the DHCP pool but getting overlap error message.
!
CISCO-881_01(config-if)#ip address 10.88.120.5 255.255.255.248<=====From DHCP pool
% 10.88.120.0 overlaps with Vlan1
!
CISCO-881_01(config-if)#ip address 192.168.0.30 255.255.255.0<======From Modem DHCP pool
% 192.168.0.0 overlaps with FastEthernet4
!
I also applied the following commands but still not working
crypto isakmp aggressive-mode disable
no crypto isakmp aggressive-mode disable
Thanks
Tazio
11-03-2021 11:14 AM
Hello,
what is the IP address of the tunnel interface on the Fortinet ? The IP address you configure on your tunnel locally needs to be in the same subnet.
Actually, post the config of the Fortinet as well.
11-03-2021 10:26 AM
Hey man, I've PM'ed you a few questions. Could you have a look at them? Thanks.
11-03-2021 10:48 AM
Tazio
I believe that the biggest problem at this point is that the tunnel is not getting an IP address. If the tunnel does not an IP address then it can not forward any IP traffic out using the tunnel.
I do not see any reason to try to use either DHCP pool to get an IP address for the tunnel. You and the engineer at the other end need to agree on what IP subnet will be used for addressing of the tunnel and then each of you need to assign an IP from that subnet for your end of the tunnel.
11-06-2021 09:24 AM - last edited on 11-25-2021 09:58 PM by Translator
Hello,
Sorry for the late reply. I had to wait for the Fortinet Engineer to get back to me.
First he told me that putting an ip address on tunnel interface would not help according to him but nevertheless to rule out anything he agreed.
He configured 192.168.42.9/24 on his side and i put 192.168.42.10/24 on my side.
Immediately i could see:
CISCO-881_01#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0 unassigned YES unset up up======>Cisco phone is connected
FastEthernet1 unassigned YES unset up down
FastEthernet2 unassigned YES unset up down
FastEthernet3 unassigned YES unset up up======>laptop is connected
FastEthernet4 192.168.0.22 YES manual up up===>WAN interface connected to Modem
NVI0 192.168.0.22 YES unset up up
Tunnel0 192.168.42.10 YES manual up up
Vlan1 10.88.120.1 YES manual up up
From Laptop I can ping 8.8.8.8 and 10.21.64.7 which is the LAN ip on Fortinet.
I will do some more tests with the Fortinet Engineer on Tuesday but wanted to make sure something.
On the cisco 881 i can ping 8.8.8.8 but cannot ping 10.21.64.7 even sourcing form t0 or F4, is this normal?
!
CISCO-881_01#ping 10.21.64.7 (May be this is normal and should not be pingable)
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.64.7, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
!
CISCO-881_01#ping 10.21.64.7 source t0 (i was thinking this would work not sure though)
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.64.7, timeout is 2 seconds:
Packet sent with a source address of 192.168.42.10
.....
Success rate is 0 percent (0/5)
!
CISCO-881_01#ping 10.21.64.7 source f4( not sure about this one)
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.21.64.7, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.22
.....
Success rate is 0 percent (0/5)
I am attaching a fresh show run
Thanks
Tazio
11-06-2021 10:15 AM
Tazio
Thanks for the update. I am puzzled that the Fortinet engineer thought that an IP address on the tunnel was not important. The results when you did configure IP addresses on the tunnel interfaces show that it is indeed important.
The most important result is this "From Laptop I can ping 8.8.8.8 and 10.21.64.7" so the encrypted tunnel is working and the Lan to Lan communication is most important.
I can understand why this ping did not work "ping 10.21.64.7 source f4"
and the key to that result is this "Packet sent with a source address of 192.168.0.22" if the source address is 192.168.0.22 then Fortinet will attempt to send the response to that address. But how would Fortinet be able to reach that IP address?
I would think that the ping sourced from the tunnel interface should have worked. That output indicates that the source address was 192.168.42.10 and that should be a connected interface on the Fortinet. I believe that there must be something on the Fortinet side that prevents that ping from being successful. Do you know anything about how the Fortinet is configured? Your router is configured to implement the encrypted tunnel using the Virtual Tunnel Interface approach. One of the important aspects of VTI is that it does not use the traditional crypto map. I wonder if the Fortinet does use a traditional crypto map?
In VTI any traffic that goes through the tunnel is encrypted. So your ping request would go through the tunnel and be encrypted. But if Fortinet is using a crypto map it must specify the source and destination addresses of traffic to be encrypted. It is clear that Fortinet has specified addresses for Lan to Lan traffic which is being encrypted (and which does work). But if Fortinet did not specify tunnel to tunnel traffic in their crypto map then that traffic would not get encrypted and the ping would fail.
I believe that the Lan to Lan traffic working is the most important thing. I would suggest that testing with ping from tunnel or from WAN addresses is not important and that you not be concerned if it does not work.
11-25-2021 08:30 AM
Hello,
Thank you all for your support and reply.
Everything is working fine for me.
Just as a side note , i was not able to ping the 10.21.64.7 form Cisco 881 because Fortinet blocked it. When they allowed ping, it worked fine
Thanks
Tazio
11-25-2021 02:17 PM
Tazio
Thanks for the update. Interesting that Fortinet was blocking the ping and that it worked when they stopped blocking it. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.
11-07-2021 02:49 AM
Hello,
do you have the Fortinet config ?
11-07-2021 01:50 PM - last edited on 11-25-2021 10:20 PM by Translator
Hello
@Tazio4436 wrote:
interface FastEthernet4
ip address dhcp
ip nat outside
FastEthernet4 192.168.0.22
ip route 0.0.0.0 0.0.0.0 FastEthernet4 dhcp
interface Tunnel0
ip address 192.168.42.10 255.255.255.0
tunnel source FastEthernet4
tunnel destination 184.94.68.98
Looks like you are double natting (modem & cisco rtr) and on the tunnel source ip to reach the tunnel destination, however you have no static translation for <192.168.0.22,192.168.42.10> and neither are public routable so how are the tunnel interfaces ips able to reach each other?
Also what you dont want to do is allow the rtr to arp for everything it supposedly thinks is directed connected via tunnel0.
no ip nat inside source list 1 interface FastEthernet4 overload
no ip route 10.21.64.7 255.255.255.255 Tunnel0
no access-list 1
access-list 100 deny ip 10.88.120.0 0.0.0.7 host 10.21.64.7
access-list 100 permit ip 10.88.120.0 0.0.0.7 any
ip nat inside source list 100 interface FastEthernet4
ip route 10.21.64.7 255.255.255.255 Tunnel0 x.x.x.x <tunnel nexthop>
Then you still have to sort out how 192.168.42.10 (which is sat behind modem 192.168.0.22) is going to be reached from the 184.94.68.98,
Do you have admin access to this modem?
Possible options - either
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide