ScreenOS Firewalls (NOT SRX)
Showing results for 
Search instead for 
Do you mean 
Posts: 16
Registered: ‎12-22-2009
0 Kudos

Splitting VPNs via Different Interfaces

Hey all, have a quick question I'm hoping someone can give me some help with. I have Googled until my eyes turned blue, scoured my ScreenOS Cookbook to no avail. I have the following:

Firewall A -- e0/0 provider 1 (T1)
           -- e0/1 provider 2 (DSL)
           -- bgr0

Firewall B -- e0/0 provider 1 (MetroE)
           -- bgr0

I had been asked to send ALL 192.168.0.x tunnel traffic MINUS 1 host via e0/1 and ONE 192.168.0.x host via e0/0 ASCII whould look like:

Firewall A --> --> via e0/1 --> Firewall B
Firewall A --> --> via e0/0 --> Firewall B

Unsure how to accomplish this. Firewall A's e0/1's default route is active and nothing I send to e0/0 gets through. The moment I gave e0/1 the better preference, is the moment all stopped. I went back and created two VPNs from Firewall A to Firewall B and vice versa, but I cannot get Firewall A's e0/0 connected to Firewall B. Any thoughts, pointers, etc?

Distinguished Expert
Posts: 826
Registered: ‎05-04-2008
0 Kudos

Re: Splitting VPNs via Different Interfaces



I came across a similar issue and resolved it by adding an interface with a unique IP on Firewall B.  I then added a 32 but route on Firewall A to ensure the second VPN routed via the second ISP.  Once both VPN's were active, I simply used trust-vr routes accordingly.  I hope this sheds some light.



John Judge

If this solves your problem, please mark this post as "Accepted Solution". Kudos are appreciated.
Distinguished Expert
Posts: 858
Registered: ‎11-02-2009
0 Kudos

Re: Splitting VPNs via Different Interfaces



As I understand you are using policy based VPN. It would be easer to work with route based VPN. But anyway, you need two VPNs. Create a MIP on eth0/0 for and use it in the VPN configuration. This NAT is required for the FW B to correctly forward the response packets. Place this VPN policy on FW A before the second one that is tunneling the entire network. Use Sorce based routing to route the packets with the source IP through eth0/0. The SBR has higher preference over the dst-routing per default. This should work.

Kind regards,