Virtual Wire deployment: vlan not crossing firewall

[Netwerx]

Greetings,

Soon I need to get our firewall off from tap mode into a virtual wire deployment. We'll be placing it between our router and core network switch, with no local secondary production subnets to worry about so virtual wire seems to be the ticket. A problem we had with a previous attempt  at this was that our phone traffic, which is voip and on its own subnet, would not traverse the firewall to the router to come back to the voip server.

From a conversation I had with a PA engineer, he said that we shouldn't have to set up a sub-interface on this, and that in the default virtual wire for Ethernet ports 1 and 2, setting the allowed tags to 0 for untagged traffic, and the other tag for our voip traffic, should do the trick.

Is there anything I could be missing here? I have the v5.0 administrators guide but would welcome any configuration examples or insights. ,

[panos · Accepted solution]

you are right configuring 0-4094 (for example) for virtual wire is enough for untagged and voip traffic.

Try to disable non-syn reject to see if anything change maybe there is something asymmetric

[Lahcen]

Hi panos and Netwerx

   I had the same problem now i'm on site and I try to deploy PA-500 in mode virtual wire, but i have done some test with voip phones and all phones are not enable to register, i'm wondering what's the problem.

   firstly i taught it's a vlan issue so instead of configuring default in Vwire tag allowed i set 0-4094. and still have the same problem. for the security rule I set allow any any.

please any ideas about this issue.

Best Regards,

[Besfort]

Hi Lancen,

May be you have solved your issue, if not try to disable non-syn reject because that did the trick for me.

You can disable it by creating a new Zone Protection profile (in Network -> Network Profiles).

In the new profile set the "Reject Non-SYN TCP" to no.

Apply this zone profile to your internal zone.

Regards,

[pulukas]

Besfort wrote:

 May be you have solved your issue, if not try to disable non-syn reject because that did the trick for me.
You can disable it by creating a new Zone Protection profile (in Network -> Network Profiles).
In the new profile set the "Reject Non-SYN TCP" to no.
Apply this zone profile to your internal zone.

Don't be quick to turn off non-syn tcp checks.  This is an important basic firewall check to insure the only valid tcp sessions are transiting the firewall.

If you need this turned off for legitimate traffic to work, you probably have asymmetrical routing on your network.  You should hunt down this routing issue and resolve the problem so that non-syn tcp checks can remain in place.

To check for asymmetrical routing perform the following steps on the two hosts of the legitimate traffic that is being blocked by the non-syn tcp check.

host A: run a trace route to host B

Host B: run a trace route to host A

These should show the same number of hops and use the same routers.  There may be different ip interfaces on the same router but the number of hops and the router hosts should all be the same.

Common causes of asymmetrical routing include:

• placing two layer 3 routers with interfaces into the same vlan
• Routing protocols that provide different metric paths between multi-hops between the hosts due to link cost settings in OSPF or local preference modifications in BGP

[Besfort]

Yes I had asymmetrical routing, and Firewall was blocking the returned traffic.

In my case the asymmetrical routing was due to using two internet connections/ISP, one as a default gateway and the other for publishing some web applications.

I have to apply PBR on the router in order for the web server replies to go through the same ISP as the request came, but for know the non-syn tcp solved the issue.