Same traffic traverses the firewall twice.

[rbit0965]

I will try to draw this out the best I can and then ask my question.

Remote Site (zone is trust, vrouter2, tunnel.1) <<>> Core network (zone is trust, Interface 1/10, vrouter2, layer3)

Rule for this is any, any in both directions.

The above is how all remote traffic flows. (all traffic hits the core)

Core Network <<>> interface 1/9 (zone is trust, Vrouter1) <<>> Out to the web (zone is untrust, Vrouter1)

What should happen:

Remote user surfs the web, Traffic comes down the ipsec tunnel

assigned a session ID by PA and logged.

And is passed on to the core.

and then passed back up to the firewall on interface1/9 where it would match a rule, gets logged, and be passed out to the web.

Here is whats happening:

Remote user surfs the web, Traffic comes down the ipsec tunnel

assigned a session ID by PA and logged.

And is passed on to the core.

and then passed back up to the firewall on interface1/9 ....

Nothing Happens. We cannot see a log or a deny at all.

remote users cannot ping the 1/9 interface.

My Originall suspicion is that the traffic is already assigned a session ID so PA drops the traffic.

To fix this I would think I need to change my tunnel and tunnel to core(1/10) connection to be their own zone.

Any ideas?

I can provided more details if needed.

[kprakash]

Can you verify if the routers on the core network ( r1, r2..rn ) have a route back to the remote network? You can either configure static routes for the remote network, such that they reach back to the IP address of eth1/10 interface. Else the easier way is to enable a dynamic routing protocol like OSPF, on the interfaces tunnel.1, eth1/10, and eth1/9 and on all the interfaces of the transit routers, so that they can dynamically learn a route back to the remote network. It appears that this is a routing issue and the transit routers do not have a route back to the remote network

Hope that helps

BR,

Karthik

[rbit0965]

I am able to ping and traceroute from 1/9 interface (via cli) to the remote site.

So i would assume all the routes are correct.

[rbit0965]

Update:

First I changed my VPN Tunnels to a newly created zone (IPSEC_Trust) and  did the same thing for the 1/10 interface.

Updated my any any rule to allow from and to IPSEC_Trust and also update my IPsec tunnels to the same Zone.

This created mixed results. Some traffic was fitting the any any rule and other traffic wasnt.

I did have both zones (ipsec_trust and trust) in the source and destination... would that fail?

I then changed 1/10 interface back to trust.

Updated my any any rule to allow from and to IPSEC_Trust and trust

All untrust traffic from the remote site now works, and shows up as two sessions on the firewall.

IPSec_Trust >> Trust

Trust >> Untrust

Is this the only solution for this?

[kprakash]

As long as we are passing traffic through the correct zones, have the correct polices, we shouldnt have any issues with the traffic. Your new configuration looks valid. We will still see 2 sessions on the firewall, because there are 3 zones being involved here.

Traffic ingressing into the IPSEC_Trust zone (tunnel.1), and egressing out via the Trust zone ( eth1/10) will have one session associated with it

Traffic ingressing into the trust zone ( eth1/9 ) and egressing out via the untrust zone (eth

Or you could configure a policy base forwarding rule with the below settings:

source zone IPSEC_Trust

source address: remote network

destination address: 0.0.0.0/0

Forwarding:

action:Forward

Egress interface: untrust interface

Next hop: Firewalls gateway

And have a security policy from IPSEC_Trust to Untrust

Be sure to have a static route route on the VR1 to have a route to the remote-network, pointing to VR2 ( ie remote-networks: nexthop VR2 )

BR,

Karthik RP

[rbit0965]

That is correct. We currently see two sessions. But our question is why did we not see two sessons before setting up the third zone?

[kprakash]

Did we verify if the eth1/9 was configured with a zone and/or virtual router ?

Your description seems contradicting:

Here is whats happening:

Remote user surfs the web, Traffic comes down the ipsec tunnel

assigned a session ID by PA and logged.

And is passed on to the core.

and then passed back up to the firewall on interface1/9  ---------------------------------------------------------------------> how did you know if the traffic reached the eth1/9 interface? If we do not have traffic logs for the traffic, it means that the traffic never reached the firewall,

                                                                                                                                                         or it would have been dropped because it did not have any zone/ v router assigned to it.

Nothing Happens. We cannot see a log or a deny at all.-----------------------------------------------------------------------> usually the case, when the traffic did not reach the firewall at all ( else there would be a deny or an allow )

remote users cannot ping the 1/9 interface. ----------------------------------------------------------------------------------------> users might not have been able to ping the interface, if the eth1/9 interface did not have any interface management profile with ping configured under it