Palo Alto in Virtual Wire mode - problem with perimeter gateway (Firewall)

[Sobolenko]

Hello everyone,

I decided to post here a question that I hope someone would be able to answer or at least provide some guide to which direction to move.

I have an opportunity to sell Palo Alto appliances to one of our clients and for that I need to show to the client that it is better that their current firewall.

So configuration:

Clients Perimeter Firewall: HA Fortinet 300C

For testing purposes: PA 2050 updated to PAN-OS 5.0.6.

Basic topology information:

Client has a Juniper router connected to WAN link, one cable goes from router to port 1 of Fortinet firewall (outside interface) and port 2 goes to LAN to core/distribution switch.

Assuming that other firewall of Fortinet is passive (it's active/passive cluster), I introduced PA 2050 as virtual wire on port 2 LAN interface of Fortinet Firewall.

The Problem:

After that no traffic is forwarded from LAN interface of Fortinet firewall to outside interface. Tracing packet from network host I can see that it reaches it's default gateway passing Palo Alto virtual wire deployment but goes no further.

I can see traffic traversing from LAN to WAN and even some applications, but speed is extremely slow and that is a prove that Palo Alto received and passes traffic.

My intuition tells me that the problem is somewhere within Fortinet (I cleaned arp cache but it didn't help) but I cannot really understand where could be the problem.

As soon as I connect back cable from Fortinet LAN interface back to core switch, everything is working again good.

Please let me know if anyone has an idea what's happening..

Thanks,

Val

[mbutt]

Hi Val,

Two things you might want to look at. If they are using VLAN's then make sure that you have tag allowed in the vwire

Below is the description of tag allowed in vwire and a snapshot of where to configure it

Network--->virtual wire---. configured virtual wire

Tags Allowed

Enter the tag number (0 to 4094) or range of tag numbers (tag1-tag2) for the traffic allowed on the virtual wire. A tag value of zero indicates untagged traffic (the default). Multiple tags or ranges must be separated by commas. Traffic that has an excluded tag value is dropped. Note that tag values are not changed on incoming or outgoing packets. When utilizing virtual wire subinterfaces, the Tag Allowed list will cause all traffic with the listed tags to be classified to the parent virtual wire. Virtual wire subinterfaces must utilize tags that do not exist in the parent's Tag Allowed list.

Secondly it would be good to have them in separate zone e.g VW-inside,VW-outside. So the logs can be seen in the traffic logs.

Network--> Zones

Now apply them to the interfaces you have the Vwires configured on

If all the above is done then make sure the security policy is allowed in both direction and no security profile is configured on it.

Once all the above has been verified and you have the traffic flowing then you can tighten up the policies and enable other features.

Also another thing you can consider is clearing the arp on the router or upstream side. If it is a modem or a connection provided i have seen where the arp does not clear out and the traffic does not flow properly on the upstream device. So if it is a small office modem or cable router then you might want to restart that as well to make sure arp is cleared on both Checkpoint and router and PA as well.

Let us know if this helps in convincing him.

Thanks

Numan

[Sobolenko]

Hello mbutt,

Thanks for fast response. I do not remember exactly - probably I left Tag Allowed option without a value, could be possible solution due to that Fortinet LAN interface is connected to core switch within VLAN 10.

Definitely not policy issue due to virtual wire interface e0 by default is untrust zone and e1 is trust zone and by policy I allowed traffic untrust from trust and vice versa (I tried to install virtual wire on WAN interface and works fine, can see traffic).

Anyway, I'll try tag allowed option this Wednesday and post results here,

Thanks again,

Val

[VinceM]

Hi,

Definitly a tag issue. If no tag is specify, only nativ vlan is allowed (vlan 0).

During test, the isisest way is to specify 0-4094 (then allow all vlan).

Hope help

V.

[Sobolenko]

Thanks Vince, hope really it is.

Tomorrow at noon time I'll try it at client's side. Will post results here.

Val

[Sobolenko]

I configured tagged traffic to pass through virtual wire connection and it didn't work. I have both security policies (inside->outside and vice versa) enabled and see traffic passing through  Palo Alto, but still web navigation is extremely slow. I didn't have a chance to restart a router and probably never will due to specific reasons for this client. As a last resort, I offered this client to configure mirror port on his core switch, but it seems like client doesn't want to continue anymore..

Will see today final answer,

Thanks for help,

Val

[VinceM]

Hi,

Does router and switch have foced speed and duplex ?

Often, slow traffic mean negotiation issue.

Hope help.

V.

[Sobolenko]

Well,

it's 1 Gbps link so definitely is Full Duplex and auto-negotiation. I will probably go with mirror port, if client will want to continue. Thanks to all for help.

[VinceM]

Hi,

Ok then if from a physocal point of vienw it's ok, try to type: show counter global filter delta yes. First time then again 5 second later andcCopy the result.

V.

[Sobolenko]

Thanks V,

I will be able to try that only on the week that start of 26 of August. I will not be able to visit that client before.

As soon as it is done - I'll post the results here,

Thanks,

Val