Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - screenie.

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 66
101
or a /32 route for each host accising the network on the router pointing to the forewall. Or anotherway of routing making sure tafiic is sendback to fw by the firewall. maybe a a /30 on the router "stolen" from the network the hosts are in? then a route to the firewall for the bigger net. Many other options......

102
Did you maybe set keep route active on the static route?

103
Set pol global any any any reject log would do this for you. Beware this overrule intra zone blocking setting.

104
To portfard you configure a VIP on the outside interface, define the service and destination on this VIP and then create a inbound policy with the VIP as destination.

105
NetScreen and SSG/ISG Series Firewalls / Re: SSG20 Intrazone Blocking
« on: June 13, 2009, 04:22:16 pm »
Can you debug with the one failing policy? Taht should show why it isn't working as it should,

set ff dst-ip <dst>
debug flow basic
start failing session
undebug all
get db stream

106
How do I route x.x.x.75 to 172.16.1.5 with the SSG320?

Three choises:

Configure a MIP on interface. IP is x.x.x.75, host 172.16.1.5. Policy destination should be MIP(x.x.x.75). Traffic comming from (initiated by that is) will be source natted to x.x.x.75.

Define a VIP on int. More or less portforwarding. Normal NAT applies for outbon traffic. Destination in policies is VIP(x.x.x.75) here.

Last: destination NET.
set arp-nat-dst.
set pol from untrust to untrust any x.x.x.75 service nat dst ip 172.16.1.5 permit log

All should work!
Setup destination nat

107
Uh, reboot the machine for a start? orange alram just means there are unread enries in the event log. May the guy onsite can read the eventlog to you? get event on console would do that.

108
You surelu shouldn't be upprised that it will cost sone money to keep a firewall up to date?! There's a lot of work to done on maintenance. For the VPN: you should be able to get every ipsec vpn working. The ScreenOS implementation of IPsec is very,very good.

To soften your mood: you bought a very good device!

109
NSM / Re: Adding routes to vrouters on clusters
« on: June 05, 2009, 02:59:15 pm »
OK, 6.1 runs the new nsrp did you try to sync routing as part if the RTO syncs?

110
NSM / Re: Adding routes to vrouters on clusters
« on: June 04, 2009, 03:12:37 pm »
You want an honest answer? Call me!

Should work on cluster level! Static routes are synced. What nsm versiomn, what ScreenOS version ?

111
Sorry, no answer but switch to ospf if you can!!!!

112
NetScreen and SSG/ISG Series Firewalls / Re: DMZ access lag time
« on: June 03, 2009, 03:50:26 pm »
I'be seen natting from trust to DMZ based upon interface mode. Shouldn't be, I know, but I saw it. So place the trust interface in route mode after you selected NAT src hide behind egress interface in every policy from trust to untrust and you're there.

113
NSM / Re: Configure Multicast with NSM
« on: June 03, 2009, 11:52:16 am »
You mean server on one interface, receiver on the other, just IGMP?

114
Did you write a global policy? That overwrite zoneblocking setting. If so: set pol from trust to trust any any any permit solves your problem!

115
So check release notes of 6.2 I could be wrong on the version number, but believe I read it somewhere.

116
What ScreenOS version are you using? I think this is a 6.1 feature.

117
Enable RIP on On VR level and then on interface level. But I like ospf a lot more! Same subnet might be a problem. Why don't you set two static routes with differnt metrics?

Like this:

Set monitoring on VPN's. This will bring tunnel int down if VPN fails.

Then routes like this:

set route x.x.x.x/x int tunnel.1
set route x.x.x.x/x int tunnel.2 metric 10

Second route will only be active when first VPN goes doen.

118
Does the eventlog show why the VPN stops?

119
would kill all communication from vsys to shared environment (untrust zone) I think.

120
IP address is correct. You could try to connect a console cable and login with with sn-number of the device as username and as password. This resets the device just as the (painfull) pinhole procedure should do.

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 66