No, I don't mean to make allegations about what your ISP is doing, just 
pointing out that
this is not ALWAYS a firewall problem.  I have seen several cases where ISPs 
drop
any packet from the internal network that tries to enter via the external 
interface.
Its done in the modem.

In these cases, I suspect they are running some form of packet filter or 
iptables and they are the
ones that are blocking your re-directs.  When this happens its not limited to 
smtp.

I just meant it as another point to check. 

You've proved you are reachable, now you have a convenience issue of 
reach-ability
from your own network.  You are half way there.

If it really is your ISP, you can still get around this with with a split 
horizon dns server,
internally, which is what I do.  But then I use iptables on linux and am I'm 
NOT knowledgeable about
pf. 

Tom Estep (shorewall) has a faq about this issue (routeback)
that applies to the iptables world http://shorewall.net/4.2/FAQ.htm#faq2 
also read faq2b at same link. 

Maybe it will help you find the equivalent setting in pf.



In my case Comcast is will not even pass packets from one cat5 port on my modem
to another port on the same modem.  I can't ssh out of one into the other. 
This is EVEN having the modem set to pass-thru mode, (turning off its internal 
firewall).
This is how I know there is something done at the modem of which I have no
control.



On 11/23/2014 07:51 AM, Soós László wrote:
> So if I understand right you suspect that my ISP is filtering out the SMTP 
> packets.
> My problem is the other way around.
>
> When I try externally  (telnet to yyyyyy.131 port 25) it works
> When I try on the OpenBSD host (which is the firewall itself) it does NOT 
> work.
>
> It looks like for me OpenBSD 5.6 does not passing up packets to pf which 
> destined to self.
>
> Maybe its a bug in 5.6 as it worked in 5.5, but maybe it is a change that I 
> did not notice in the
> changelog.
>
>
> Laszlo
>
> 2014.11.23. 1:28 keltezéssel, Jason Adams írta:
>> On 11/22/2014 12:50 PM, Soós László wrote:
>>> Telnet on the same host (command run on the OpenBSD host) - BAD, UNEXPECTED 
>>> BEHAVIOUR
>>> -------------------------------------------------------------------------------------
>>> [root ~]#  telnet yy.yy.yy.131 25
>>> Trying yy.yy.yy.131...
>>> telnet: connect to address yy.yy.yy.131: Connection refused
>> If y.yy.yy.131 is your External Interface (attached to your cable modem, (or 
>> what ever), you
>> should test from somewhere else, such as your cell phone NOT connected to 
>> your wifi, or a shell
>> on some remote machine.
>>
>> I say this because connections "out-the-in-again" are commonly being blocked 
>> by some modems
>> these days.  In particular I have this problem in Comcast, and have torn 
>> more than a few hairs
>> trying to fix it, only to find it was intentional on their part.
>>
>>
>


-- 
Those who do not understand Unix are condemned to reinvent it, poorly.

Reply via email to