1
General Discussion / Re: HA with 2 BGP sessions/transfer networks - asynchronous routing/NAT (configprob)
« on: August 19, 2022, 04:46:33 pm »
Hey mimugmail,
thanks for your reply. To be honest we kinda hoped for an answer from your side, because we read your name in countless other threads on the seek for help and you seemed to always have an answer. Besides that, we are both from munich
However, your answer is not a very productive one. It completly kills any discussion and gives everyone a nice reason not to interact with our problem, which is (at least in our opinion) not the way an "ask for help" should be answered.
We are aware, that opnsense is not the "one size fits them all" product and completly agree with the part that says "you could do that better/easier with other vendors". Sadly we currently don't really have this choice, since ressources and possibilites are not endless on our end.
So let me rephrase our question a little bit - hopefully this will lead to some more interactive discussion (which might still lead to "it doesn't work", but with a solid "why"):
Both of our opnsense firewalls by themselves route and NAT traffic perfectly fine. Our sole issue is redundancy of the upstream gateway. Since we can not establish multpiple BGP Sessions on a single firewall, we need a different solution.
Would it be possible to tell the firewalls that they have two gateways, one being the BGP Neighbour of the ISP and the other, with a lower priority, the other firewall? So that in the case where firewall A is online and its BGP Neighbour is online, everything is routed through its configured BGP session. In case it is online but the BGP neighbour is not, it routes its traffic via the other firewall (since their BGP neighbour is most likely up).
Also we are aware that we have a state problem in the case where traffic flows asynchrounously inwards via Firewall B and outwards via Firewall A. Let's (for the sake of the discussion) ignore this fact for a second, because we would try to solve this problem as soon as we have the gateways sorted out.
Thanks again for your reply, we really hope to read again from you soon.
Best regards, arti
thanks for your reply. To be honest we kinda hoped for an answer from your side, because we read your name in countless other threads on the seek for help and you seemed to always have an answer. Besides that, we are both from munich
However, your answer is not a very productive one. It completly kills any discussion and gives everyone a nice reason not to interact with our problem, which is (at least in our opinion) not the way an "ask for help" should be answered.
We are aware, that opnsense is not the "one size fits them all" product and completly agree with the part that says "you could do that better/easier with other vendors". Sadly we currently don't really have this choice, since ressources and possibilites are not endless on our end.
So let me rephrase our question a little bit - hopefully this will lead to some more interactive discussion (which might still lead to "it doesn't work", but with a solid "why"):
Both of our opnsense firewalls by themselves route and NAT traffic perfectly fine. Our sole issue is redundancy of the upstream gateway. Since we can not establish multpiple BGP Sessions on a single firewall, we need a different solution.
Would it be possible to tell the firewalls that they have two gateways, one being the BGP Neighbour of the ISP and the other, with a lower priority, the other firewall? So that in the case where firewall A is online and its BGP Neighbour is online, everything is routed through its configured BGP session. In case it is online but the BGP neighbour is not, it routes its traffic via the other firewall (since their BGP neighbour is most likely up).
Also we are aware that we have a state problem in the case where traffic flows asynchrounously inwards via Firewall B and outwards via Firewall A. Let's (for the sake of the discussion) ignore this fact for a second, because we would try to solve this problem as soon as we have the gateways sorted out.
Thanks again for your reply, we really hope to read again from you soon.
Best regards, arti