Juniper Junos – Managing Multiple Interfaces on SSG

interfaceispjuniper-junosnat;routing

Okay guys I have a conundrum on my network, I do not know how it is working, I just know it does. I have a Juniper SSG firewall with 3 different ISPs. I have traffic coming in through the 3 interfaces, but somehow all outgoing traffic is sent through interface 1. How can this be possible?

Example:
Client A sends a packet to Server B behind Juniper ethernet 0/1 ISP. Server B responds to Client A but the response is sent to Client A via ethernet 0/0. How does Client A know the response is valid if the response came from a different public IP? The same exact path is provided to the other ISP on ethernet 0/2, any signals that come in to the Juniper SSG on ethernet 0/2 are replied to through ethernet 0/0. These "servers" are alarm Receivers communicating to alarm panels on the field.

Further, if the ISP for ethernet 0/0 goes down (it is set as our primary for outbound), and Server B starts to reply to Client A on ethernet 0/1 or ethernet 0/2 they start screaming. (alarm signal receivers talking to panels on the field)

We have tested this and this is the way it appears to work. We do not understand why or how. Has anyone seen this before?

The reason we are asking is because we are looking to replace the Juniper SSG with a different product and we would like to replicate this same

Best Answer

This issue occurs with your Quad Zero route. You have routes bound to interfaces and if you are fulfilling requests from a priv or dmz interface and you have a 0.0.0.0 route offered on that interface that is the path the return traffic will take to get back to the requesting source. If you need the traffic to return from the interface it was received from your will need to redo your routing on the device.

Suggestion

If you have a service window you can schedule.

Research how you would like your 0.0.0.0 routing to work per interface. I would imagine you might have some end user requests for Internet passing through the device too and that would need to be taken into consideration.

Modify your txt config file to what you believe is functional and load it up during your service window.

Have your testing regiment planned out and try and hit every item. If you fall into an abyss, load your config that you know is functional and return to a steady state and revisit the issue during your next window. Plan it, test it, nail it. Good luck.

Related Topic