Traffic Leaking out of Balance380 Interface IP


#1

Hi,

I’m having trouble with traffic that is leaking out of the Peplink’s interface IP instead of the WAN IP that NAT is set up on. I know that this is expected behaviour during a WAN outage, but this seems to be happening all the time. Normally this wouldn’t be much cause for alarm, but the traffic that is leaking is outbound email, which is not getting delivered because it’s coming from the wrong IP. This is also happening on multiple WAN interface IPs.

My setup is somewhat complicated, but here goes. I have two servers behind an external IP address, one is the MTA (Message Transfer Agent) which accepts inbound/outbound SMTP traffic and the other server is a tracker that only does inbound HTTP traffic. So there is no 1:1 NAT used here but a combination of Services, Outbound NAT mappings, and Outbound Policy. There are actually 2 external IPs for the server to enable a bit of reputation management on the IP addresses, but they are both on the same WAN.

So recently I checked IP reputation through senderscore.org and it said that one of the two IPs had not sent any email, which was interesting because my MTA had records of sending just under 100k emails through that IP address. I started auditing my WAN subnet to find the ‘missing email’ and discovered that my Peplink’s interface IP now had a senderscore.org reputation, and a bad one at that. I looked at my other WAN link which also has different servers in the same configuration and found that that interface address had also gained a reputation.

I’ve double checked my settings and I don’t see what I’m doing wrong, but at the very least is there a way to create a firewall rule that can block the interface IPs from being allowed to deliver SMTP traffic? They should not be doing that because it is ruining my deliverability.


#2

You can block unwanted inbound and outbound traffic to/from LAN hosts with firewall rules in the Balance. Peplink should not send out SMTP traffic itself unless you are using the email notification feature.

You can monitor active sessions under: Status> Active Sessions. For a more thorough investigation, you can also do a network capture from the Balance if that is helpful. I would encourage you to open up a support ticket with us here if you need help resolving this so we can obtain the necessary information.


#3

Hi Ron,

I am using the email notification feature, but the volume of email generated for that isn’t causing the problem. I’ve tried looking in active sessions to see the behaviour, but I haven’t witnessed it yet. As far as the rules go, I put one in place that should do the blocking. It uses the interface IP as the Source IP with Any port, Destination is Any with port 25, and the action is Deny with logging. I still haven’t see anything pop up in the event log to say that it’s blocked traffic, but I know that traffic is leaving that way because of email headers that I checked in external test email accounts.

It seems a network capture could be the next best step, thanks for the suggestion. This is a pretty critical feature for my organization, so depending on how that capture looks I might just do the support ticket.


#4

I’m experiencing a similar issue with a new MediaFast 500. I’ve set up an outbound policy to send outgoing SMTP connections (LAN to Internet) to go out through one of the additional Public IP addresses for each of three ISPs we are using as well as corresponding NAT mappings to enforce the use of these non-interface IP addresses, yet SMTP connections are still going out under the respective interface IP addresses. The MediaFast is running firmware version 6.1.2 build 1203. I already opened a support ticket which has since been escalated to the advanced troubleshooting team but still have no fix. Hopefully this is just a bug in the current firmware release as we really need to control which public IP addresses are used for these outbound connections.

Note that in my case, this also impacts non-SMTP outbound connections so I don’t think this is just an issue for SMTP.


#5

Thanks for the reply! I haven’t noticed this behaviour outside of SMTP, but that’s probably because most of my other outbound connections rely on the interface IPs of our Balance380. How long ago did you open your ticket out of curiosity? My company has a division that is an email service provider, so it’s critical for us to have absolute control over which IPs are sending email.


#6

Kudos to Peplink Support for their quick resolution on this issue. It turns out that it was a configuration issue (read: user error) that caused the SMTP traffic to go out the interface. Ron diagnosed and solved the problem in about 5 minutes flat!

Thank you Ron and Jason!