ScreenOS Firewalls (NOT SRX)
Reply
Contributor
maclan13
Posts: 25
Registered: ‎01-19-2009
0

NAT vs Route on interface Problem

Quick question, when changing an interface from Route mode to NAT, does the firewall need to be restarted.

 

VLAN 10 <<>> SSG <<>> VLAN 6

 

Originally the interface between VLAN 10 and the SSG was in Route mode.  I changed it to NAT but was not getting the results I was looking for.  I changed the interface mode back to Route but now I cannot ping systems on VLAN 6 from VLAN 10.  However, I can still ping from VLAN 6 to VLAN 10 but not the other way around.  I have confirmed that all policys and routing is correct.  Would I have to restart the firewall?  Is this a common porblem?

 

Richard.

Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 789
Registered: ‎07-26-2008
0

Re: NAT vs Route on interface Problem

Hi there

No, you should not need to restart the FW for that change.

I think its better you run a debug to see why you are not able to ping.

 

set ff src-ip X.X.X.X

set ff dst-ip X.X.X.X (X is the IP of the server sending the ping)

 

cl db

debug flow basic

--> Run the ping test

get db str ( to view the captured data)

 

We can see if FW is dropping packets from the debugs or if there is something else causing the ping to fail.

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
maclan13
Posts: 25
Registered: ‎01-19-2009
0

Re: NAT vs Route on interface Problem

[ Edited ]

Below is the output I get after pinging from vlan 10.  I sent 5 pings and thus have the same message repeated 5 times.  I need abit of help interpreting.  Looks like the ping is not passing the firewall.

 

I have two SSGs setup with Active/Active HA.  The one these logs are from is my primary that is in VSD group 3.  Why do you think the logs are referring to VSD 4?  The interface that this packet should be exiting is ethernet1/3.6:3

 

 ****** 5298702.0: <Trust/ethernet1/2> packet received [100]******
  ipid = 104(0068), @2e5a5110
  packet passed sanity check.
  ethernet1/2:172.16.10.7/4->172.16.6.2/20,1(8/0)<Root>
  no session found
  flow_first_sanity_check: in <ethernet1/2>, out <N/A>
  chose interface ethernet1/2 as incoming nat if.
  flow_first_routing: in <ethernet1/2>, out <N/A>
  search route to (ethernet1/2, 172.16.10.7->172.16.6.2) in vr trust-vr for vsd-0/flag-0/ifp-null
  [ Dest] 34.route 172.16.6.2->172.16.6.2, to ethernet1/3.6:4  ***Wrong destination route, connected active route is ethernet1/3.6:3***
  routed (x_dst_ip 172.16.6.2) from ethernet1/2 (ethernet1/2 in 0) to ethernet1/3.6:4
  policy search from zone 2-> zone 102
 policy_flow_search  policy search nat_crt from zone 2-> zone 102
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 172.16.6.2, port 49147, proto 1)
  No SW RPC rule match, search HW rule
  Permitted by policy 36
  No src xlate   choose interface ethernet1/3.6:4 as outgoing phy if
  check nsrp pak fwd: in_tun=0xffffffff, VSD 4 for out ifp ethernet1/3.6:4
  vsd 4 is inactive, packet should be forwarded
  Nsrp forwarding session created
  existing vector list 20-9ae45e4.
  Session (id:255722) created for first pak 20
  flow_first_install_session======>
  nsrp msg sent.
  flow got session.
  flow session id 255722
  vsd 4 is inactive, packet should be forwarded

Message Edited by maclan13 on 01-19-2009 05:09 PM
Message Edited by maclan13 on 01-19-2009 05:09 PM
Message Edited by maclan13 on 01-19-2009 05:13 PM
Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 789
Registered: ‎07-26-2008
0

Re: NAT vs Route on interface Problem

Could you show on the FW which you got the debugs, what is the output from :

get rout ip 172.16.6.2

get ha

 

Is there a specific reason why you are using Active/Active NSRP Design?

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
maclan13
Posts: 25
Registered: ‎01-19-2009
0

Re: NAT vs Route on interface Problem

From the info below is there a way on this firewall to force the  ethernet1/3.6:3 interface to be the main route.  the HA was configured by a previous employee, not sure why because we are not making full use and from my readings, some thing are not configured correctly.  I am trying to straighten things out.

 

get route ip 172.16.6.2

 

SSG-cluster1:Grenada-SSG-1(M)-> get rout ip 172.16.6.2
 Dest for 172.16.6.2
--------------------------------------------------------------------------------------
trust-vr       : => 172.16.6.11/24 (id=34) via 0.0.0.0 (vr: trust-vr)
                    Interface ethernet1/3.6:4 , metric 0
trust-vr       : => 172.16.6.10/24 (id=3) via 0.0.0.0 (vr: trust-vr)
                    Interface ethernet1/3.6:3 , metric 0

 

get ha doesn't work. did get nsrp vsd.  Hope this gives some insight.

 

SSG-cluster1:Grenada-SSG-1(M)-> get nsrp vsd-group

VSD group info:
init hold time: 8
heartbeat lost threshold: 3
heartbeat interval: 1000(ms)
master always exist: disabled
group priority preempt holddown inelig   master       PB other members
    3       50 yes            3 no       myself  1359232
    4      100 no             3 no      1359232   myself
total number of vsd groups: 2
 

 

Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 789
Registered: ‎07-26-2008
0

Re: NAT vs Route on interface Problem

Sorry can you try the following:

get route | i 172.16.6 (want to check if the vsd 3 route is actually active or not)

get int e1/3

get int

 

maybe we can get more info from this.

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
maclan13
Posts: 25
Registered: ‎01-19-2009
0

Re: NAT vs Route on interface Problem

The web interface says that it is active.  I can ping 172.16.10.X from the 172.16.6.2 machine. Just not the other way.

 

SSG-cluster1:Grenada-SSG-1(M)-> get route | i 172.16.6
*        20      172.16.6.0/24            n/a        trust-vr   S   20      1     Root
*        11    10.160.0.160/27     eth1/3.6:3      172.16.6.1   S   80      1     Root
*        34      172.16.6.0/24     eth1/3.6:4         0.0.0.0   C    0      0     Root
*         3      172.16.6.0/24     eth1/3.6:3         0.0.0.0   C    0      0     Root
*         4     172.16.6.10/32     eth1/3.6:3         0.0.0.0   H    0      0     Root
*        35     172.16.6.11/32     eth1/3.6:4         0.0.0.0   H    0      0     Root
*        40      172.16.6.0/24            n/a        trust-vr  CI  140      0

 

SSG-cluster1:Grenada-SSG-1(M)-> get int e1/3
Interface ethernet1/3:
  description ethernet1/3
  number 11, if_info 26488, if_index 0, mode route
  link up, phy-link up/full-duplex
  vsys Root, zone Back Office Servers, vr trust-vr, vsd 0
  dhcp client disabled
  PPPoE disabled
  admin mtu 0, operating mtu 1500, default mtu 1500
  *ip 0.0.0.0/0   mac 001f.1214.bf0b
  *manage ip 0.0.0.0, mac 001f.1214.bf0b
  pmtu-v4 disabled
  ping enabled, telnet disabled, SSH disabled, SNMP disabled
  web disabled, ident-reset disabled, SSL disabled
  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
  OSPF disabled  BGP disabled  RIP disabled  RIPng disabled  mtrace disabled
  PIM: not configured  IGMP not configured
  NHRP disabled
  bandwidth: physical 1000000kbps, configured egress [gbw 0kbps mbw 0kbps]
             configured ingress mbw 0kbps, current bw 0kbps
             total allocated gbw 0kbps
Number of SW session: 255972, hw sess err cnt 0

 

 

SSG-cluster1:Grenada-SSG-1(M)-> get int

A - Active, I - Inactive, U - Up, D - Down, R - Ready

Interfaces in vsys Root:
Name           IP Address                        Zone        MAC            VLAN State VSD
eth0/0         0.0.0.0/0                         Null        001f.1214.bf00    -   D   -
eth0/1         0.0.0.0/0                         Null        001f.1214.bf05    -   D   -
eth0/2         0.0.0.0/0                         Null        001f.1214.bf06    -   D   -
eth0/3         0.0.0.0/0                         HA          001f.1214.bf07    -   U   -
eth1/0         0.0.0.0/0                         Untrust     001f.1214.bf08    -   U   -
eth1/0:3       208.XXX.XXX.X/29                   Untrust     0010.dbff.2083    -   U   3
eth1/0:4       208.XXX.XXX.X/29                   Untrust     0010.dbff.2084    -   I   4
eth1/1         0.0.0.0/0                         Null        001f.1214.bf09    -   D   -
eth1/2         172.16.10.3/24                    Trust       001f.1214.bf0a    -   U   -
eth1/3         0.0.0.0/0                         Back Offic~ 001f.1214.bf0b    -   U   -
eth1/3.4       0.0.0.0/0                         Back Offic~ 001f.1214.bf0b    4   U   -
eth1/3.4:3     172.16.4.2/24                     Back Offic~ 0010.dbff.20b3    4   U   3
eth1/3.4:4     172.16.4.3/24                     Back Offic~ 0010.dbff.20b4    4   I   4
eth1/3.6       0.0.0.0/0                         Back Offic~ 001f.1214.bf0b    6   U   -
eth1/3.6:3     172.16.6.10/24                    Back Offic~ 0010.dbff.20b3    6   U   3
eth1/3.6:4     172.16.6.11/24                    Back Offic~ 0010.dbff.20b4    6   I   4
eth1/4         0.0.0.0/0                         Null        001f.1214.bf0c    -   D   -
eth1/5         0.0.0.0/0                         Internal U~ 001f.1214.bf0d    -   U   -
eth1/5:3       172.16.24.1/24                    Internal U~ 0010.dbff.20d3    -   U   3
eth1/5:4       172.16.24.2/24                    Internal U~ 0010.dbff.20d4    -   I   4
eth1/6         0.0.0.0/0                         Provisioni~ 001f.1214.bf0e    -   U   -
eth1/6:3       172.16.24.189/28                  Provisioni~ 0010.dbff.20e3    -   U   3
eth1/6:4       172.16.24.190/28                  Provisioni~ 0010.dbff.20e4    -   I   4
eth1/7         0.0.0.0/0                         Interlink   001f.1214.bf15    -   U   -
eth1/7.1       0.0.0.0/0                         Interlink   001f.1214.bf15   91   U   -
eth1/7.1:3     10.160.96.5/29                    Interlink   0010.dbff.2153   91   U   3
eth1/7.1:4     10.160.96.6/29                    Interlink   0010.dbff.2154   91   I   4
tun.1          unnumbered                        Untrust     ethernet1/0:3     -   U   -
tun.2          unnumbered                        Untrust     ethernet1/0:4     -   D   -
tun.3          unnumbered                        Untrust     ethernet1/0:3     -   U   -
tun.4          unnumbered                        Untrust     ethernet1/0:3     -   U   -
tun.5          unnumbered                        Untrust     ethernet1/0:4     -   D   -
loopback.1     172.16.14.3/24                    Untrust     N/A               -   U   -
vlan1          0.0.0.0/0                         VLAN        001f.1214.3f0f    1   D   -
null           0.0.0.0/0                         Null        N/A               -   U   0
SSG-cluster1:Grenada-SSG-1(M)->

 

Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 789
Registered: ‎07-26-2008
0

Re: NAT vs Route on interface Problem

hmm.. Looks like its taking the route ID which is topmost on the routing table:

 

SSG-cluster1:Grenada-SSG-1(M)-> get route | i 172.16.6
*        20      172.16.6.0/24            n/a        trust-vr   S   20      1     Root
*        11    10.160.0.160/27     eth1/3.6:3      172.16.6.1   S   80      1     Root
*        34      172.16.6.0/24     eth1/3.6:4         0.0.0.0   C    0      0     Root <--Note that 34 is before 3
*         3      172.16.6.0/24     eth1/3.6:3         0.0.0.0   C    0      0     Root

 

If you unplug the interface on the OTHER firewall and plug it back in, I think that will move the route ID to be below that of ID 3, but its not going to be a permanent solution for you.

Its better to redesign the setup with A/P if you do not really use the A/A though. Also in A/A you need to take note that in the event of a failover, 1 fw will need to be able to support the load that both were carrying.

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
maclan13
Posts: 25
Registered: ‎01-19-2009
0

Re: NAT vs Route on interface Problem

No luck with pulling the cable.  I think I'll have to schedule a restart of the firewall, was hoping to aviod that.  I'll investigate cleaning up the A/A HA config also.

 

One more thing.  Logging into and out of the firewall to  run the debug commands and now I seem to be locked out. Allssh and webui sessions time out.  Is there a way to recover from this other than restart?

Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 789
Registered: ‎07-26-2008
0

Re: NAT vs Route on interface Problem

Which ScreenOS are you running? Does the console still work?
****pls click the button " Accept as Solution" if my post helped to solve your problem****
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.