SFR sensor registration with FireSight over VPN - Not Working

[remi-reszka]

Hello security experts,

I have an ASA5515-X with SFR 5.4.0 installed and manage it with FireSight 5.4 installed on VM on LAN and I can register the sensor without any issues but when I try to register the sensor to FireSight over VPN I cannot do it. The MGMT interface on ASA does not have IP nor nameif configured and the interface is connected to the switch, SFR has the IP configured same as the LAN addressing. I can see the traffic being exchanged between the sensor and the FireSight however I can't register the sensor.

Has anybody managed to register the sensor over VPN? Is there anything else to be configured to be able to register the sensor with the MC over the VPN?

The delay between the Firesight and the Sensor (over WAN and VPN) I get is between 80 and 100ms, that could be the problem?

Many thanks!

Remi

[Aastha Bhardwaj]

Hi,

Did you try using the NAT id for registration ?

++Delete the manager from sensor by command : configure manager delete

++Make sure its deleted and then add it again with NAT id , nat id is just a unique number that you configure both on sensor and DC.

You should be able to telnet from DC to sensor on port 8305 initially if connectivity is fine, once that is there you should be able to register.

Check it and let me know if that works.

Regards,

Aastha Bhardwaj

Rate if that helps!!!

[remi-reszka]

Hello Aastha,

Thank you for your reply. I tried to telnet from the DC to the sensor but I get "Connection Refused".

On the ASA log I get the following:

Dec 17 2015

11:47:17

10.26.8.61

49804

10.20.110.2

8305

Teardown TCP connection 10168 for vpn:10.26.8.61/49804 to lan:10.20.110.2/8305 duration 0:00:00 bytes 0 TCP Reset-O

6

Dec 17 2015

11:47:17

10.26.8.61

49804

10.20.110.2

8305

Built inbound TCP connection 10168 for vpn:10.26.8.61/49804 (10.26.8.61/49804) to lan:10.20.110.2/8305 (10.20.110.2/8305)

And the sesnsor responds fine from the DC:

admin@fsight:~$ sudo ping 10.20.110.2
Password:
PING 10.20.110.2 (10.20.110.2) 56(84) bytes of data.
64 bytes from 10.20.110.2: icmp_req=1 ttl=58 time=77.1 ms
64 bytes from 10.20.110.2: icmp_req=2 ttl=58 time=78.3 ms
64 bytes from 10.20.110.2: icmp_req=3 ttl=58 time=78.3 ms
64 bytes from 10.20.110.2: icmp_req=4 ttl=58 time=77.5 ms
64 bytes from 10.20.110.2: icmp_req=5 ttl=58 time=77.8 ms

I also tried with NAT id and no success. What number do I insert into NAT id? Maybe I put some wrong number, I used 123456 on both sides, not sure if that is correct.

Best regards,

Remi

[Aastha Bhardwaj · Accepted solution]

Hi,

If you are unable to telnet from dc to sensor on port 8305 then its connectivity issue.

Can you try to ping from sensor to DC :

ping -M do -c 20 -s 1572 <DC ip address>

By default the MTU is 1500 on eth0 , If the ping doesn't work I will suggest you to lower down the MTU on the interface and see if that works.

Also check :/var/log/messages |grep sftunnel , and see any error messages on both DC and sensor and send it across to me.

Regards,

Aastha Bhardwaj

Rate if that helps!!!

[remi-reszka]

OK great, let me check that I will post the results.

Telnetting into the sensor is intermittent, however the ICMP response is very stable. Could it be down to MTU on the interfaces?

Best regards,

Remi

[Aastha Bhardwaj]

Hi,

I did not get that are you able to ping with the command suggested by me , if yes then there is o need to bring down the mtu , check /var/log/messages and check for messages related to sftunnel.

Regards,

Aastha Bhardwaj

Rate if that helps!!!

[remi-reszka]

Hi,

Many thanks! With the command suggested by you I can PING from the DC towards the sensor and from the sensor to the DC only with the following:

sudo ping -M do -c 20 -s 1372 10.26.8.61

Anything above 1372 I do not get response. That could be causing the issue?

For the messages you we are looking for, can you just tell me how I can check it on the DC and the sensor?

Thanks!

[remi-reszka]

The VPN I'm using is IPSec DMVPN with use of Cisco routers 2851 and 1921, also using FVRF and IVRF.

[remi-reszka]

From the DC to sensor:

admin@fsight:~$ sudo ping -M do -c 20 -s 1372 10.20.110.2
PING 10.20.110.2 (10.20.110.2) 1372(1400) bytes of data.
1380 bytes from 10.20.110.2: icmp_req=1 ttl=58 time=119 ms
1380 bytes from 10.20.110.2: icmp_req=2 ttl=58 time=119 ms
^C
--- 10.20.110.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 119.224/119.444/119.664/0.220 ms

admin@fsight:~$ sudo ping -M do -c 20 -s 1373 10.20.110.2
PING 10.20.110.2 (10.20.110.2) 1373(1401) bytes of data.
^C
--- 10.20.110.2 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9044ms

admin@fsight:~$

[remi-reszka]

From the sensor to the DC:

admin@sfr:~$ sudo ping -M do -c 20 -s 1372 10.26.8.61
PING 10.26.8.61 (10.26.8.61) 1372(1400) bytes of data.
1380 bytes from 10.26.8.61: icmp_req=1 ttl=58 time=120 ms
1380 bytes from 10.26.8.61: icmp_req=2 ttl=58 time=120 ms
1380 bytes from 10.26.8.61: icmp_req=3 ttl=58 time=118 ms
1380 bytes from 10.26.8.61: icmp_req=4 ttl=58 time=119 ms
1380 bytes from 10.26.8.61: icmp_req=5 ttl=58 time=120 ms
^C
--- 10.26.8.61 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 118.825/120.086/120.791/0.816 ms


admin@sfr:~$ sudo ping -M do -c 20 -s 1373 10.26.8.61
PING 10.26.8.61 (10.26.8.61) 1373(1401) bytes of data.
ping: sendmsg: Message too long
ping: recvmsg: Message too long
WARNING: kernel is not very fresh, upgrade is recommended.
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.20.110.2: icmp_seq=1 Frag needed and DF set (mtu = 1400)

--- 10.26.8.61 ping statistics ---
1 packets transmitted, 0 received, +20 errors, 100% packet loss, time 0ms

admin@sfr:~$

[remi-reszka]

Sorry, how do I grab the results of:

:/var/log/messages |grep sftunnel

Thanks a lot!

[Aastha Bhardwaj]

Hi,

SSH on the defense center and sfr , escalate the privilege to root by the command :

sudo su

And then you can do a cd /var/log , less messages |grep sftunnel

Regards,

Aastha Bhardwaj

Rate if that helps!!!

[remi-reszka]

Hi Aastha ,

I looked for the sftunnel messages on both DC and the sensor and did not find anything, I guess that is good news.

But guess what, I managed to fix the issue and indeed the problem was the MTU on GRE Tunnel interfaces of the routers. I had it set to 1400 and changed to 1500 is it OK or I should go for 1524? So now with MTU set to 1500 it works like a charm. I had to do the registration using the NAT id however (without it it would not register) and I inserted a numerical value, I guess it can be pretty anything here.

I wanted to thank you so much for giving me a very good hits. Without them I would have still troubles to make it work.

Can I contact you in case I stumble on any other troubles?

Once again, thanks very very much and all the best!

Remi

[Aastha Bhardwaj]

Hi Remi,

Glad to know issue is resolved. :) , Keep posting on Cisco Support Community and i will keep helping you.

Regards,

Aastha Bhardwaj

[remi-reszka]

An update:

I managed to telnet to the sensor from the DC but only once. I closed the connection and tried again but same problem - connection refused:

admin@fsight:~$ sudo telnet 10.20.110.2 8305
Trying 10.20.110.2...
Connected to 10.20.110.2.

That could be causing the registration problem? The thing is if I try to telnet from the DC on LAN I also get the "connection refused" but I can register the sensor without any issues, only over a VPN I have problems.

I also tried using NAT id on both ends of the value 123456 and no joy.

Thanks!