Email notifications not working - firewall settings?

[alastairstevenson]

Also, in terms of the 'conversation' between source and destination, under TCP that will be underpinned by the initial connection setup between the 2 devices that enables the subsequent traffic flow.

Look for what's known as the 3-way handshake.
Depending on what's being done between the source and destination, there can be several sets of these.
It consists of a SYN packet sent from the source to the destination, with an SYN-ACK acknowledgement from the destination, following by the ACK final confirmation by the source to establish the connection.
When the data exchange dialogue is finished with a FIN, the connection is taken down with an ACK.

Look for any RST reset packets - these can be part of an access attempt rejection.

This control dialogue will be very easy to spot and easy to follow in the Wireshark capture.
It's probably the first thing to check out that may be different between the successful and unsuccessful email tests.

 

[Whoaru99]

The starting pattern is clear, as you've described.

With the firewall rule turned off (email notifications working) -

• Camera sends SYN
• Google responds with SYN, ACK
• Camera sends ACK

With the firewall rule turned on (email notifications not working) -

• Camera sends SYN
• (no SYN, ACK reply)
• Two instances of retry with no reply

The million-dollar question, then, is why does the 465 or 587 exception not work? Better yet, how to fix it, it being block LAN traffic but allow email notifications to work?

Perhaps now the answer is clear to some, but not to me.

 

[alastairstevenson]

From what you've clearly described you have now narrowed down the cause to the initial outbound connection attempt being blocked.
It could have been much more difficult to figure.
So now, as you have said, how to configure the firewall to allow that is the problem.

 

[alastairstevenson]

The million-dollar question, then, is why does the 465 or 587 exception not work?

As a long shot as an experiment, try 'Any' instead of the IP address range for the Source in your Priority 1 rule.

 

[Whoaru99]

I changed the 587 rule (rule 1) to allow -

• all source interfaces
• all IP
• all destinations

Still email does not get out unless I disable rule 2.

 

[alastairstevenson]

Well, that does show that the rule isn't matching the traffic is aimed at.
But why? It's not obvious.
Can you show the selection detail used to create the rule itself? Though you've suggested it's as open as it can be.

 

[Whoaru99]

Does this help?

First picture is with rule 1 and rule 2 disabled. Email notifications work.

Second picture is with rule 1 disabled and rule 2 enabled. Email notifications do not work.

These are what I got from Wireshark when I used the conversation function on the instance of camera trying to hit Google after I pushed the email test button in the camera GUI.

 

[Whoaru99]

And in the router...

 

[Whoaru99]

Well, that does show that the rule isn't matching the traffic is aimed at.
But why? It's not obvious.
...

Is the problem not 465 or 587 at all? Rather, since all LAN traffic is normally blocked, the pass rule must be for those camera high ports, eg. 4390x?

 

[crw030]

You have the firewall rule set to "log packets that match this rule", can you check the logs to see if there is a log entry when you try to send the email with the firewall on? It would probably show something about the packet being dropped and indicating the rule (or passed, and indicating the rule).

At this point the firewall could be dropping the outbound packet, or blocking the SYN/ACK packet, but based on how your rule is setup (and my limited knowledge) that looks like it ought to work. I know from your perspective it's "not getting out" but because it has to pass traffic in BOTH directions to establish a connection, a problem passing data in EITHER direction would look pretty much the same -- broken.

Although I don't think they would be functionally different, could try creating two rules that are top priority: first with LAN-ANY-587-ALLOW second: WAN-ANY-587-ALLOW (basically instead of ANY for interface, add the two interfaces)

 

[Whoaru99]

@crw030

Our last two posts were close to crossing. What do you think about post #29?

 

[alastairstevenson]

Rather, since all LAN traffic is normally blocked, the pass rule must be for those camera high ports, eg. 4390x?

The assumption is that it's a stateful firewall and that it implicitly allows a return packet that's covered by the TCP connection that's been set up.
But based on the wireshark interpretation here :

With the firewall rule turned on (email notifications not working) -

• Camera sends SYN
• (no SYN, ACK reply)
• Two instances of retry with no reply

the initial SYN is not getting out if there is no SYN-ACK response.
But the firewall rules log should be able to confirm or deny that this packet has been dropped.
I'd have a dig around in the firewall logs to get more detail.

 

[crw030]

Is the problem not 465 or 587 at all?

Typically the source port does not matter so much because the nature of communication are source ports are high random ports (and packets returning from a source with a firewall that maintains state) get returned to the original source ip. This Linksys interface for setting rules is different than pfSense, because it does not clearly indicate whether the port is source or destination, so it is not impossible that is the source of our problem.

Clearly the firewall thinks the first rule does not apply to either the SYN or ACK packet, we need to figure out which it is dropping. Looking at it, and comparing it to the Wireshark trace (which is all TCP and 587) I don't see why communication in either direction is being blocked. I'm a novice at this, so it might be obvious to someone with more experience, but when in doubt I go look at the logs because firewall logs typically provide a lot of detail to aid in troubleshooting as it shows the packet, source ip/port, destination ip/port and firewall action (passed or blocked).

 

[Whoaru99]

I'll have another look at the logs but I don't recall seeing anything containing reference to port 465 or 587.

 

[crw030]

You may have to TEMPORARILY turn on logging for the 2nd rule that you think is catching everything. I say temporarily because, "ALL TRAFFIC FROM LAN" is going to trigger a LOT of log entries if you leave it turned on, and since (at least my ASUS router) used FLASH with limited writes, leaving it on can cause you other problems down the road.

 

[Whoaru99]

Actually, the logging has been on for rule 2 as well. I still don't see any references to port 587 in the system log, outbound log, or incoming log. I have checked the boxes for logging allowed policy and deny policy.

There isn't a way to directly export the logs. I need to set up email on the router then (try, LOL) to send them that way. Else, try to copy and paste into Excel or whatever.

 

[alastairstevenson]

There isn't a way to directly export the logs

With a web GUI, varies with the browser though -
Select all or drag | Copy | Paste to a text editor.
Print to PDF

 

[Whoaru99]

Sorry...still have not got a copy & paste or anything to show in that regard.

But, the only way it seems I can get SYN & ACK records regarding port 587 into the firewall/router logs is to disable the rule for the LAN that's blocking everything (rule 2 in the post 25 picture).

I even tried what you see below (even though you fellows said I shouldn't need to due to SPI) just because I've got about all my hair pulled out, but it still didn't work.

 

[crw030]

Do you have Dual WAN? (I see you have a rule for WAN as well as WAN1) ?

I wonder if the problem is the stateful firewall sees the connection going out WAN and the response is dropped because it is coming back on WAN1. I cant remember what that's called but I read about it somewhere.

 

[Whoaru99]

This is the single WAN model. LRT224 has dual WAN.