Quantcast
Channel: All ScreenOS Firewalls (NOT SRX) posts
Viewing all 2577 articles
Browse latest View live

Re: ssg 5 vlan sub int dhcp

$
0
0

add source nat to the egress interface in the advanced tab of the policy.

 

set policy id 45 from "guest" to "Untrust"  "Any-IPv4" "Any-IPv4" "ANY" nat src permit log


Re: ssg 5 vlan sub int dhcp

$
0
0

i added the policy, but i still have no Internet Connection, only with intern vlan 1 ....

 

when i put the interface to zone "trust" it works - so there is a problem with my created zone "zone3".

 

-> i created a new zone guest, added the same policy and no it works fine!

 

thanks steve for your help - i really appreciate it !

Backup WAN interface vpn tunnel

$
0
0
I have a client with a Juniper SSG 550 latest version Screen OS that wants to send all his VPN traffic using his backup ISP connection. He will use his main ISP for web traffic. I know I can send traffic to the bavkup WAN via souce routing. My question is, How do I make my backup WAN ip available from the internet to set up a VPN tunnel. Is there a special route to make my backup WAN ip available from the internet?


Thanks

Re: ssg 5 vlan sub int dhcp

$
0
0

Glad you have it all worked out.

Re: Backup WAN interface vpn tunnel

$
0
0

I assume you are using the built in WAN failover similar to this configuration.

 

http://forums.juniper.net/t5/Configuration-Library/ScreenOS-Configure-Backup-Internet-Interface-with-Automatic/m-p/84294#M247

 

So the issue is that this option will keep your backup internet offline until it is needed.  And all your traffic then shifts to the secondary path.

 

To keep both ISP active you will need to change how your local routing for the ISP and default routes are setup to allow both to be active and make sure the default route out the primary ISP works but the VPN traffic uses the second ISP.  I think the simpliest solution here then is:

 

place the secondary ISP into a virtual router

Add a secondary default route to this VR into the main router

Add ip tracking to the first ISP to take this offline when this ISP goes down so the secondary route becomes active

Then build your primary tunnel to the second ISP and your secondary VPN to the primary ISP switching their current setup

Re: Backup WAN interface vpn tunnel

$
0
0

Adding IP tracking would cause the physical interface to go down.

 

Are you using multiple interfaces (One interface for primary and a second for backup)?  If so, then you could use IP tracking.

Re: Backup WAN interface vpn tunnel

$
0
0

Thanks for the reply,

 

I am about to test your recommendations, but I have a couple of questions.

 

I will set up both WAN interfaces on the same Zone as recomended by your link and follow up all your recommendations

 

http://forums.juniper.net/t5/Configuration-Library/ScreenOS-Configure-Backup-Internet-Interface-with-Automatic/m-p/84294#M247

 

Here is where I have some questions

 

place the secondary ISP into a virtual router

> add backup-vr and add the default route to my backup WAN default Gateway ?

Add a secondary default route to this VR into the main router

> from the trust-vr create a second 0.0.0.0/0 for backup-vr, with a higher preference value?(meaning down unless the lower preference goes down)

Add ip tracking to the first ISP to take this offline when this ISP goes down so the secondary route becomes active

> Tracking from the backup interface to the primary interface, no problem

Then build your primary tunnel to the second ISP and your secondary VPN to the primary ISP switching their current setup

> Will this changes make my backup interface active? if it does I can then set up a tunnel to my backup interface IP. The tunnel is just for DR traffic and I do not need to fail it to the primary interface. Right now I can only use my backup interface via source routing, but the backup WAN ip is not available from the internet to set up a VPN tunnel.

 

Thanks for your help. let me know if I understood your recommendations correctly.

 

Re: Backup WAN interface vpn tunnel

$
0
0

Yes I have 2 interfaces and 2 ISP's I do not want or need to failover the traffic. Just need to create a tunnel to the Backup WAN interface that is not available from the internet yet. At least is not available via ping yet


Re: Backup WAN interface vpn tunnel

$
0
0

This did not worked, Still cannot reack the backup WAN from my remote Firewall. I guess is a routing issue since all te request reach the backup interface, but when the reply is issue everything gets routed to my primary interface.

 

 

Re: Backup WAN interface vpn tunnel

$
0
0

You don't need to put the zone into a different VR.  The information in that discussion is for failover.  Just specify the host address to the remote gateway in the VR.

 

set route <IP of VPN gateway>/32 int <backup WAN> gate <next hop>

You would then configure the VPN gateway to use the backup WAN as the outgoing interface.

 

If you are using a route based VPN, then you would need to configure a tunnel interface and set routes for the internal addresses on the remote site to use the VPN.

 

set route <internal remote> int tunnel.<number>

Re: Backup WAN interface vpn tunnel

$
0
0

Thanks,

 

I guess I was not understood.

 

I have 2 Junipers(ont local, one remote) so I would prefer to use a policy based tunnel. My remote Juniper firewall only has one WAN connection, I assume there will be no changes on that side. On my local firewall with 2 WAN conections (Primary and Backup WAN) I will need to add the following route.

I am using trust-vr for my local traffic and untrust-vr for the default gateway routes

 

 

set route <IP of remote firewall>/32 int <backup WAN> gate <next hop>

 

Will the ping to the backup interface work? even adding this route I cannot ping the Backup WAN from my remote Firewall. Should I just go ahead and set up the VPN tunnel?

 

 

Thanks

Re: Backup WAN interface vpn tunnel

$
0
0

It worked when I moved my Backup ISP route to the untrust-VR with th eprimary route

Re: adding a vsys upgrade license

$
0
0

All good. It seems there was some confusion since these firewalls had EOL announcement. But, I received the auth code and generated the license and applied it with no issues

 

Thanks for your help.

SSG140 | Huge udp packet losses

$
0
0

Good afternoon,

 

We are trying to solve out some strange issue with pair of SSG140 (6.3.0r23.0). We do see lot of UDP packet losses there, that can be 37% when traffic is around 1 (one) Mbps. So, for exampe, if we do test with 512Kbps -> almost no drops (1%), 1Mbps -> 37%.

 

One interesting thing: it's only for outbound traffic, not for inbund ... 

 

We tested that only on SSg140 (2 different pairs) - behaviour always the same. Any help?

Re: SSG140 | Huge udp packet losses

$
0
0

I suspect the issue is more with PPS and not bandwidth for the issue.  I've seen this situation in running tests on other platforms using traffic generators.  the UDP streams have very small packet size so getting the higher bandwidth numbers tends to general very high packet per second streams and this PPS folds the device at much lower than expected bandwidth levels.


Re: SSG140 | Huge udp packet losses

$
0
0

Good morning,

 

Ok, but I don't think that 1Mbps should create any issues for SSG140 ... I do expect a bit more from that device ... Are my expectations incorrect?

 

Just did pps "metering"

 

PPS counting is enabled on interface(number 0) ethernet0/0
59: 378 303

 

PPS counting is enabled on interface(number 6) ethernet0/2
59: 467 536

 

From Juniper SSG 140 spec:

Firewall packets per second (64 byte) 90,000 PPS, 90kPPS vs mine rate ... I think it;s bit too less Smiley Sad

Re: SSG140 | Huge udp packet losses

$
0
0

Hi ,

Traffic of 400-500 PPS on SSG-140 is very less on the FW. Interface traffic handling capacity might not be causing this issue?

Can you please answer the below mentioned queries which would help us to understand the issue better:

+ Have you made any change after which the issue appeared?
+ How do you suspect that FW is inducing the latency?
+ Can you please give us a brief idea about topology?
+ Have you tried to bypass the FW and performed the test if there is improvement in the throughout?
+ Do you face the same issue with the TCP traffic as well?
+ What are the CPU levels , Duplex settings on the interface incoming and outgoing and the polic configuration on the FW?
+ Aer your using any traffic shaping , UTM features or not ?

Regards
Rishi Surana

Re: SSG140 | Huge udp packet losses

$
0
0

Good morning,

 

+ Have you made any change after which the issue appeared?

 

No, it's a new installation


+ How do you suspect that FW is inducing the latency?

 

I don't see latency, but I see packet drops. Even look for the pps from test above, incoming is bigger then whatever has been done by eth0/0 (untrust)

 

Test like VM1 -> ESX1 -> SWITCH -> ESX2 -> ESX2 shows no drops

Same test, but when it requires to be routed via SSG interface i.e.

 

VM1 -> ESX1 -> SWITCH -> SSG140 -> SWITCH -> ESX2 -> ESX2 - .same exact amount of 37% drops


+ Can you please give us a brief idea about topology?

 

VM Machine -> ESX -> 1000/full -> 3750-24(stack) -> 100/full -> SSG140 -> 100/full -> ISP


+ Have you tried to bypass the FW and performed the test if there is improvement in the throughout?

 

We have no issue when laptop connected to the uplink port ("ISP port")


+ Do you face the same issue with the TCP traffic as well?

 

Nope, only UDP affected


+ What are the CPU levels , Duplex settings on the interface incoming and outgoing and the polic configuration on the FW?

 

PHX-CLSmiley Tonguehx-fw1(M)-> get performance cpu
Average System Utilization: 1%
Last 1 minute: 2%, Last 5 minutes: 2%, Last 15 minutes: 2%

 

Each interface configured with static 100/full/1500


+ Aer your using any traffic shaping , UTM features or not ?

 

Nothing, just a policy.

 

 

P.S. Just be aware that drop rate for 1Mbps traffic is always 37%, I saw once 35% and 36%, but then 99.9% of time it's 37%

Re: SSG140 | Huge udp packet losses

$
0
0
PPS counting is enabled on interface(number 0) ethernet0/0
59: 378 303
PPS counting is enabled on interface(number 6) ethernet0/2
59: 467 536

Yes, clearly you are not dealing with PPS issues.

 

Since the packets are dropped on the untrust interface check your "screen" counters and see if these increment to match the drop conditions.  Your traffic may be detected as malicious and being dropped by these protective measures.  If so you will need to adjust the untrust screen settings.

 

get interface ethernet0/0 screen

Re: SSG140 | Huge udp packet losses

$
0
0

I checked all possible counters, I don't see any of them are increasing ... 

 

Also, I did ff /with debug flow drop ... all that kind of investigations I'm aware off ... it doesn't help and it doesn't explain where packets are.

 

I'm confused ...

Viewing all 2577 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>