Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
icom
New Contributor

Can I change VPN administrative distance without creating trouble?

Hi, 

 

I have problems with creating a Site-to-site between a 60E(behind nat/router and a old Juniper FW. 

The fortigate is claiming the tunnell is up and the same about the juniper, but no traffic is passing

 

last log entry on juniper:IKE 85.x.x.x Phase 2 msg ID e17d3fc6: Completed negotiations with SPI 694e0051, tunnel ID 7, and lifetime 3600 seconds/0 KB.

 

On both Fortigate and Juniper i created firwall policies and added static routes.

 

Is this about interface administrative distance? 

On my fortigate my vpn interface is having a distance of "10" and my 0.0.0.0/0 is set to 5 (WAN1)

 

Can is change my vpn distance without causing any trouble? I wonder if this is the problem.. that my fortigate is trying to route through WAN1 and not VPN/IPSEC.

 

 

20 REPLIES 20
emnoc
Esteemed Contributor III

That's good  you tunnel has no packets

 

{ stat: rxp=0 txp=0 rxb=0 txb=0 }

 

Check routing

 

 

get route info routing all

 

And validate the  routing is correct and run the diag debug flow command

 

 

e.g

 

diag debug reset

diag debug en

diag debug  flow filter 172.22.22.1 172.22.22.254

diag debug flow show console enable

 

 

diag debug flow trace start 100

 

 

Then start a ping from a inside machine to something at mtero_remote, do you get a match? Does it show accept ? Does it hit the vpn gateway  metro ?

 

the good thing you seem to have a PH2 tunnels ;)

 

dec: spi=841d9218 esp=3des key=24 742e5be2abc6526fcff689e82135d62b78f0c88e4c887c99   enc: spi=694e01d7 esp=3des key=24 0be392fc9cb4d58e3aaedec540462dcb018bab2d15fc5f96

 

 

So that's half of the battle ;)

 

 

Ken

 

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
icom
New Contributor

thank you for your great support. 

 

The strange thing is.. the vpn tunell is suddenly passing traffic and I dont understand why? I guess those command you gave me did not alter anything in my configuration?

 

The last thing i did on both sides earlier today was to change mss from 1500 to 1350. 

 

 

emnoc
Esteemed Contributor III

Monitor  the  interface and tunnel but  no those commands did not   modify anything  in the cfg. I woud  run the  two cmds ( FGT/Juniper ) and ensure that the traffic is passing and allowed by the fwpolicy

 

Ken

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
icom
New Contributor

I can now pass traffic between those two FW and I can pass traffic between computers over the tunnel. 

 

I hope it was the mss adjustment i did because that will atleast make sense. Owner on one of the sites told me he had a DSL connection and in my experience a IPSEC MTU of 1500 is a bad choice over DSL. 

 

 

 

icom
New Contributor

a little follow up on this.

 

the tunnel is suddly not passing traffic.. When i try to do a sniffing this is the result:

 

# diag sniffer packet Metro interfaces=[Metro] filters=[none] pcap_lookupnet: Metro: no IPv4 address assigned 16.764178 192.168.22.158 -> 172.22.22.2: icmp: echo request 22.105572 192.168.22.158 -> 172.22.22.2: icmp: echo request 27.605790 192.168.22.158 -> 172.22.22.2: icmp: echo request 33.105940 192.168.22.158 -> 172.22.22.2: icmp: echo request

rwpatterson
Valued Contributor III

run a traceroute and see where you traffic is headed...

 

Debug is your friend, still.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
icom

Tracert from computer:

 

Trace 172.22.22.1 (from 192.168.22.158)

1 <1 ms <1 ms <1 ms 192.168.22.1 2 * * * no reply 3 * * * no reply 4 * * *  5 * * *  6 * * *  7 * * *  8 *

Fortigate with sniffing the ipsec tunnel

3037.695693 192.168.22.158 -> 172.22.22.1: icmp: echo request 3044.130590 192.168.22.158 -> 172.22.22.1: icmp: echo request 3050.719674 192.168.22.158 -> 172.22.22.1: icmp: echo request 3055.098529 192.168.22.158 -> 172.22.22.1: icmp: echo request 3059.622348 192.168.22.158 -> 172.22.22.1: icmp: echo request 3064.093864 192.168.22.158 -> 172.22.22.1: icmp: echo request 3068.591848 192.168.22.158 -> 172.22.22.1: icmp: echo request 3073.106091 192.168.22.158 -> 172.22.22.1: icmp: echo request 3077.605646 192.168.22.158 -> 172.22.22.1: icmp: echo request 3082.086696 192.168.22.158 -> 172.22.22.1: icmp: echo request

32 packets received by filter 0 packets dropped by kernel

 

emnoc
Esteemed Contributor III

Will your diag sniffer shows that your traffic is leaving the tunnel metro. Did you do a diag debug flow and does the other end allow that traffic

 

Ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
icom
New Contributor

No FW rule changes on the juniper is done..  the tunnel went ut passed traffic.. the day after, no traffic (but tunnel is still up). I'll check out the firewall on the juniper. 

 

on the other hand - why wont this command work on the FGT?

 

diag debug flow show console enable

command parse error before 'console' Command fail. Return code -61

icom
New Contributor

i really dont understand a thing. 

 

I've been pinging between these two sites all day. To traffic passing. 

I've just sat down with this, logged into web gui of the juniper to check firewall logs, and then SSH into juniper for testing some  "get" commands like "get route" and "get flow" .. and suddenly the ping start to respond and pass traffic again. 

 

I have no clue of what is happening. Something similar happend a couple a days ago. No passing traffic for hours and days.. I log in to do some troubleshooting and suddely it's passing traffic. 

 

What the h... 

 

 

 

 

 

 

Labels
Top Kudoed Authors