12-15-2008 07:57 AM
Client has two SSG-140 connected via a satellite. when we ping both the sites with some cisco router or through some machines, they ping successfully but the ping response time varies from 1100ms to 1500ms.
But when we put ssg-140 on both ends, both the ssg's unable to ping each other.if we use extended ping from both SSG's and when we use the time 2 or 3 seconds instead of defualt time which is 1 (one) second, ping started to get success response and reply ttl is around 1100 to even 2200. it fluctuate between this ttl.
Now we have established route based vpn between both SSG's and even vpn is established but after 2 to 3 minutes we were unable to access the data from both SSG's LAN.
how to increase default time level or is there any other solution ???
configs and screen shots of ping replies from both the devices are attached with this message. Thanks in advance.
12-15-2008 01:10 PM
Looking at your configuration, the service is specified as ANY in the policy.
tcp timeout is 30 mins
udp timeout is 1 min
icmp timeout is 1 min
If you change the timeout on the ANY service, it may well be changing all the service timeouts.
The command to change the default settings are:
ssg5-isdn-wlan-> set service <name> timeout <N>
However, looking at your problem description, it does not seem like a session timeout issue. I would recommend that you run the following debugs to make sure that things are working correctly:
set ff src-ip A.A.A.A
set ff dst-ip A.A.A.A
debug flow basic
---> Esc to stop the debugs
get db str (to check the debug info)
You should run this on both the firewalls when the icmp traffic is not being passed correctly. Looking at the logs to see if there are any "dropped" packets should be able to tell you as to whether there are packets being dropped incorrectly.
Also another question is that in general if you have configured ospf on the tunnel interfaces, in general you would not need the static routes on the firewall to route the traffic.
Also looking at this route:
set route 172.18.10.0/24 interface tunnel.1
The same route seems to be set statically on both the remote and HQ site, thats definitely not correct.
Hope this helps.
12-16-2008 02:11 AM
i think badar means that his latency on his link it that high (1,2 to 1,5 sec) that the ping of vpnmonitor is never gona work.he is saying that the default timer of vpnmonitor is 1 sec.
so vpn is always going down.
Is this your problem badar?
if so i think you can make it a bit better with optimized enabled on your vpn monitor (then he will not ping when there is already traffic flowing over the vpn.)
still 1,2 a 1,5 sec is very high latency (i don't have that on a satelite connection (using wxc there so, so he will lower the latency alot), what kind of connection is this?
And i don't know of any command to change the default ping timeout for vpnmonitor.
12-16-2008 06:10 AM
Hi WL and Frac,
Let me give you little bit more information. when we make VPN between both SSG's and data started to flow between both locations, if we have the flow with small packet size then no problem, but as we pass some large data packets then we can see the request timed out and after one or two min it again get stable. its the bank, when they have transactions which is a small text, till this time traffic is fine but if the branch try to access some internet traffic or any other application which has large data size then this outage occurs.
They are using satellite connection from Comstar satellite provider, Traffic has to be slow through satellite but it should not give an outage in case of large data transfer.
Hope you will come up with some good help
12-16-2008 06:44 AM
When I've seen services set to 'never', its always been a problem in the past, since the session table relies on RST or FIN packet to erase the session, and these aren't always delivered for various reasons. Over time, the session table maxes out.
Maybe you can test with long lived sessions, but if the protocols are timing out on the hosts, this wouldn't help. I would go with WL's debug suggestions. Sniffer traces would also be good. At the moment, the requirement is to determine what is causing large data transfers to fail. Sniffer traces and debug should help to explain what the hosts are sending/receiving, and the firewall is processing.
12-16-2008 07:17 AM
this isn't a problem of service timeouts.
> to be sure check the get session ds-ip <ipofremoteserver> (look at the "time" field), check if session is still there.
if the session is still there, its just a problem of bandwith/latency/application. (what kind of application is this)
problem with vsat is bandwith and latency. so if someone takes all bandwith some applications could fail/timeout.
maybe qos can be a solutions here, or like we always do on vsat connection => WXC.
But 1 check the session table of both firewalls when the application seems to freeze/end.
12-17-2008 06:51 AM
Based on this last posting, I would check the MSS settings.
Run the command: get flow | inc vpn
and see what the TCP MSS is set to for VPN packets.
If it is not set, I would try setting it to 1350 with the command: set flow tcp-mss 1350
Let us know how it goes,
01-05-2009 05:39 AM
I tried this MSS option, but as soon as we start OSPF on the SSG-140, it starts timed out and packets starts dropping. Result is the same with MSS setting as it was before. Please provide some other solution. If you require i can send u the configuration ????
01-06-2009 08:23 AM
1. Typically we don't hardset the MTU on an interface unless there's a specific need.
Can you unset the MTU settings on the tunnel interfaces on both firewalls:
unset interface tunnel.x mtu 1500
Then also set the 'set flow tcp-mss 1350', and re-describe the symptoms.
2. What ScreenOS version are you running on both SSGs?
3. Observation (not related to your issue):
Typically on the VPN Monitor settings for route-based VPNs running OSPF, the rekey option is also specified, i.e.
set vpn <vpn> monitor optimized rekey
Refer to the following for more info: http://forums.juniper.net/jnet/board/message?board.id=Firewalls&message.id=1298&query.id=661827#M129....
4. Observation (not related to your issue):
Policy id 2 on NAWABS-SSG is a vulnerable policy.
At least specify specific from and to host IPs.
Once you get it all working (you don't want to do too many changes at once), you may put your tunnel interface in a 'VPN zone', and then create the policies from and two the Trust and 'VPN Zone'. Refer to the following for an example: KB7746 - Full Mesh VPN with OSPF.