So did the debug flow drop stream show the packets exist but are not dropped?
What does dbug flow basic show for the session handling of your traffic stream?
Can you share the debug files?
↧
Re: SSG140 | Huge udp packet losses
↧
Re: SSG140 | Huge udp packet losses
Fresh debug:
PHX-CL
hx-fw1(M)-> get ff
Flow filter based on:
id:0 src ip 10.100.1.133 dst ip 216.218.227.10
id:1 src ip 216.218.227.10 dst ip 10.100.1.133
PHX-CLhx-fw1(M)-> get debug
flow: basic
file is attached. I can't see anything strange here.
P.S. Personal meaning - issue is related to MTU / fragmentation, but I can't find what exacty is wrong 
↧
↧
Re: SSG140 | Huge udp packet losses
Correct, the debugs clearly show the traffic is permitted and assigned to the same flow.
One thing I notice is that there seems to be a lot of fragmentation on the flow. Can you confirm the MTU settings end to end are all matching (if you haven't already).
If that checks out you could try lowering the mss to 1350. I have occasionally seen problems with some ISP where lowering mss prevents packet loss on flows particularly when fragmentation is a factor.
↧
Re: SSG140 | Huge udp packet losses
Tried mss option, no effect, I got my "favorites" 37% of drops
↧
Re: SSG140 | Huge udp packet losses
Hi,
I can cleary understand that the there is fragmentation for the UDP traffic which most probably is causing the latency. Reducing the MSS value will only avoid the fragmentation for TCP traffic and will not be application for UDP traffic.
During the time of the issue please provide me with the output of "get session frag" and also packet captures on end to end device along with snoop on the FW with debug flow basic .
As we are generating 1 MBPS of traffic which is either fragmented on the device or being recieved as the fragmented traffic is might be choking the fragmentation queues on the device hence causing the packet drops.
You can try to reduce the payload of UDP segment from application end or you can try to configure Path MTU to avoid fragmentation:
# https://kb.juniper.net/InfoCenter/index?page=content&id=kb7049&actp=search
This is all we can do on the firewall to improve performance.
Regards,
Rishi
↧
↧
Re: SSG140 | Huge udp packet losses
OK, Guys, I'm totaly confused now:
take a look for the packet capture I did and for the snoop from juniper. Can be that juniper just dicard packets when it hit some rate?
I do remember we had an issue with ISG 1000 / 2000 when it were able to drop packet without any notification once tcp timer expired (i.e. firewall was thinking that session is expired), while endpoint were trying to 're-establish" connection.
↧
Re: SSG140 | Huge udp packet losses
Ok, Gentelmens, Thank you all for the help, issue found. Looks like it's all due the output queue drops on the switch itself.
↧
Re: SSG140 | Huge udp packet losses
Hi ,
I tried to trace the UDP flow stream to investigate the drops below is my observations:
+ I found that in the below stream the first fragment has not being received on the device due to which the succeeding fragments are are queued and after waiting for 3 sec (default timeout) the fragments are dropped which is the root cause of this issue. This would increament fragments aged out in "get session frag".
63052.0: ethernet0/2(i) len=1518:005056a2c0d0->0010dbff2060/8100/0800, tag 3
207.38.68.135 -> 216.218.227.10/17
vhl=45, tos=00, id=18645, frag=20b9, ttl=64 tlen=1500
frag offset=1480 more fragment=1
63052.0: ethernet0/2(i) len=1518:005056a2c0d0->0010dbff2060/8100/0800, tag 3
207.38.68.135 -> 216.218.227.10/17
vhl=45, tos=00, id=18645, frag=2172, ttl=64 tlen=1500
frag offset=2960 more fragment=1
63052.0: ethernet0/2(i) len=1518:005056a2c0d0->0010dbff2060/8100/0800, tag 3
207.38.68.135 -> 216.218.227.10/17
vhl=45, tos=00, id=18645, frag=222b, ttl=64 tlen=1500
frag offset=4440 more fragment=1
63052.0: ethernet0/2(i) len=1518:005056a2c0d0->0010dbff2060/8100/0800, tag 3
207.38.68.135 -> 216.218.227.10/17
vhl=45, tos=00, id=18645, frag=2000, ttl=64 tlen=1500
frag offset=0 more fragment=1
udports 52661->5201, len=8200
+ I suspect that first fragment is getting dropped either on the upstream device to on the FW interface , to confirm the same
+ I suggested if we need the end machine is sending the segments with the size 7400 bytes which is causing the fragmentation over the network. To avoid this enable PMTU on end machine or tune the size of the segment at application layer.
+ In the meantime we can try to understand which device is dropping the traffic (first fragment)
Can you please provide me with the below mentioned logs during the time of the issue for more analysis :
+ Debug flow basic simultaneoulsy with snoop
+ get session frag
+ Get counter stat <5-10 time >
Regards,
Rishi
↧
Re: SSG140 | Huge udp packet losses
Hi,
Its a good news that the issue got resolved , Please refer my latest analysis and explaination as well.
I request you to mark the solution as accepted or mark as Kudoes 
Regards,
Rishi
↧
↧
Re: SSG140 | Huge udp packet losses
Thanks for the update on the root cause And glad you have it working now.
↧
Re: ssg 140 firmware needed
Hi,
Anyone can share the ssg140 screenOS 6.2.
Ali
↧
Re: ssg 140 firmware needed
Hi Ali,
You can download the 6.2r19 firmware from the below mentioned link :
# https://www.juniper.net/support/downloads/?p=ssg140#sw
Note: This firmware is signed with the new key
Regards,
Rishi
↧
SIP sessions allocation error message
Dears,
i have a screenOS 6.3 running on Juniper SSG350m firewall, recently i found log messages saying
"Cannot allocate SIP call because device is fielding too many calls"
after a quick search i found an article saing that i can increase the max number of sip calls using this command
set env max_sip_call_num= Value
and then a reboot is needed for the firewall,
my question is, after a confirmation on the above steps, what is the maximum number of SIP calls SSG350 can handle?
below output is current configuration on the firewall and i need to increase it to its maximum.
get alg sip setting
SIP ALG : enabled
Maximum number of SIP Calls : 128
Maximum Call Duration : 43200 seconds
Inactive Media timeout : 120 seconds
T1 interval : 500 milli seconds
T4 interval : 5 seconds
C interval : 3 minutes
SIP hold retain resource : Disabled
SIP Application Screen Configuration
-------------------------------------
Unidentified messages in nat mode : dropped
Unidentified messages in route mode : dropped
SIP denial of service protect timeout : 5
SIP global denial of service protect : Disabled
SIP denial of service protect server IP :
↧
↧
Re: SIP sessions allocation error message
max sip call number: 256
↧
Re: SIP sessions allocation error message
Hello,
Just to add to what 'rseibert' has said: You can use below command to find out the maximum SIP call capacity of any device.
2301-> get sys-cfg | in SIP
default sip call num number: 192
max sip call num number: 384
Regards,
Rushi
↧
IKEv2 to replace L2TP/IPSec dialup VPN
We have been running L2TP/IPSec for a quite some time already (SSG550 / 6.3.0r23.0).
Decided to switch to IKEv2 as it suppose to be simpler solution.
We did some testing, run into something I don’t understand...
Could somebody comment what I’m doing wrong exactly?
Setup:
strongSwan as client / strongSwan as server / SSG550 as server
strongSwan has really good logging, so it’s easy to see what’s going on under the hood.
I’m not able to get any useful logging from Win7+ client at all...
I’ll describe test configs from ScreenOS view:
I have 2 ikev2 gateways with corresponding vpns
1.
set ike gateway ikev2 "Gateway - IKEv2 RSA" auth-method self rsa-sig peer rsa-sig
set vpn "VPN - IKEv2 RSA" gateway "Gateway - IKEv2 RSA" no-replay tunnel idletime 0 proposal "test2"
2.
set ike gateway ikev2 "Gateway - IKEv2 EAP" auth-method self rsa-sig peer eap
set vpn "VPN - IKEv2 EAP" gateway "Gateway - IKEv2 EAP" no-replay tunnel idletime 0 proposal "test2"
#1 (self rsa-sig peer rsa-sig) works fine from both strongSwan and Win7 clients.
However, the goal is to get EAP working.
#2 (self rsa-sig peer eap) works from strongSwan if it is the only gateway+vpn defined on ScreenOS.
As soon as rsa-sig/rsa-sig gateway+vpn are created, they "shadow" rsa-sig/eap pair completely...
Problems with #2:
1.
It looks like when ScreenOS looks for matching ikev2 gateway, it doesn’t take into account received IKE ID and always uses rsa-sig/rsa-sig gateway if it exists?
2.
It doesn’t work from Win7 client.
When it's configured as IKEv2 + EAP-MSCHAP v2, it always sends IP4 as IKE ID.
I’ve no idea how to configure what IKE ID is sent by Win7 client in such case...
From another hand, ScreenOS Dialup User/ Group setup require having IKE ID, but there is no way to Dialup User with something like IKE ID IPADDR 255.255.255.255 (to match any IP for Win7 client).
Is there any workaround?
Other servers with #2 setup:
Both strongSwan and Win7 clients can connect to strongSwan server without problem.
The latter can accept both rsa-sig/rsa-sig and rsa-sig/eap at the same time unlike ScreenOS.
According to Cisco docs, #2 works Win7 client just fine too. It’s not exactly relevant to this discussion, but worse to mention still.
↧
How I can make BGP configuration on SSG-140
Hi I have new primary ISP which offered us /24 IP range via BGP. Could you please send me information to activate BGP for both ISP ports on mine SSG140 Firewal.
Primary ISP- ethernet0/2
backup ISP- ethernet0/3
Thank you in advance!
↧
↧
Re: How I can make BGP configuration on SSG-140
Hello,
You can make use of the below article.
https://www.safaribooksonline.com/library/view/screenos-cookbook/9780596510039/ch17s02.html
To prefer one ISP path over other, you can use local preference as mentioned below:
https://www.safaribooksonline.com/library/view/screenos-cookbook/9780596510039/ch17s12.html
Regards,
Rushi
↧
Basic configuration for juniper SSG140
Iam going to install SSG140 between the WAN (192.168.1.0/24 FE0/2) and Ucopia-DHCP server (Guest Wi-Fi user manager 10.154.214.126/30 FE0/0) iam wonder if some one can help me by the initial basic routing setting setup for this senario i appreciate that.
↧
Re: Basic configuration for juniper SSG140
Hello,
What functionality you want your SSG140 to serve? Is it acting as as DHCP Relay to WAN PCs?
Regards,
Rushi
↧