Jump to content


Reverse Routing Interface Mismatch

NG Firewall Advanced Routing

This topic has been archived. This means that you cannot reply to this topic.
1 reply to this topic

#1 Remko H

Remko H
  • Members
  • 5 posts

Posted 26 February 2016 - 07:47 AM

I came across a problem at a customer that I can't seem to solve.


Situation is as follows:


They have two different Internet Lines (two different providers).


One (ISP1) delivers their public wan directly to the barracuda using DHCP

The other (ISP2) has a router in front of our barracuda that does a full DMZ to an internal 192.168.x.x ip that is configured on the barracuda and the barracuda handles it from there.


We have configured source based routing for the network so the barracuda can determine how to route traffic and everything is working (surfing over ISP1 Fallback over ISP2) and the rules are also working nicely.
Except one:


Incoming SMTP traffic.


They can accept mailtraffic from the entire world except their DHCP public wan range. Mail coming from that range (it is a /19 range) the rule gives a Reverse Routing Interface Mismatch error.

The kicker is, the incoming mails are incoming from ISP2. 


I have tried enabling tcp raw mode.

Creating a rule to route the traffic over the ISP1 route ...

with no success.


Interface mismatch keeps happening.


As it stands I asked the customer to let me change their MX record so the ISP1 WAN IP is the primary MX.

But this is not the ideal solution.


anyone has any ideas how to solve this?

#2 Bartek Moczulski

Bartek Moczulski
  • Barracuda Team Members
  • 102 posts

Posted 26 February 2016 - 08:08 AM

If other hosts in ISP1 subnet do not try to go directly for your customer ISP1 public IP, but go all way around via ISP2, it means your ISP delivers different netmasks to different customers. You can disable interface checking in the firewall rule (by default it's "Matching", change to "Any"), but this will allow triangle (a.k.a. asymmetric) routing and any stateful firewall on the way will block it.


The proper solution is to have matching netmasks for all devices in ISP1 subnet (provided I understood you correctly)