[afnog] Cannot connect to remote pop3 server

[Shepherd Magumo]

Nishal,

Thanks for a detailed analysis of the problem. I got a reply from
Graham yesterday and while testing I also noticed that of the four
lines we have with ISP1, one of them is connecting on 110 to the
server and is in the 196/8 block.

If only I could get someone to listen from the two providers :(

On Thu, Feb 19, 2009 at 11:58 AM, nishal goburdhan
<nishal at controlfreak.co.za> wrote:
>
> On 18 Feb 2009, at 11:02 PM, Shepherd Magumo wrote:
>
>>> From my desktop my tracert results are not showing any intersecting
>>
>> network unless if I am missing something.
>
> in your intial mail the traceroutes showed AS174;  you'll probably find that
> a well-placed local-pref changed that...
>
>
>> is there a
>> possible that .za IP blocks are being pop3 filtered on the zonnet.nl
>> server?
>
> i actually thought that this might be the case, and tested this.
> whereas non 196/8 sourced connections seemed to work just fine, after failed
> attempts from a dozen or so hosts in different part of 196/8, on different
> networks, that did look like that was the case.  connections sourced in
> 196/8 mostly didn't work, until:
>
> # ifconfig em0 inet
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
>        inet 196.34.133.38 netmask 0xffffff00 broadcast 196.34.133.255
>
> # telnet 62.58.50.236 110
> Trying 62.58.50.236...
> Connected to webmail.versatel.nl.
> Escape character is '^]'.
> +OK POP3 Ready 10.170.1.177 0001f2e1
> quit
> +OK QUIT
> Connection closed by foreign host.
>
> # tcptraceroute 62.58.50.236 110
> Selected device em0, address 196.34.133.38, port 61879 for outgoing packets
> Tracing the path to 62.58.50.236 on TCP port 110, 30 hops max
>  1  csw1-b-jup-bry-vl2610.ip.isnet.net (196.34.133.253)  9.151 ms  9.127 ms
>  9.972 ms
>  2  core2a-bry-gi0-0-0.ip.isnet.net (168.209.217.2)  9.957 ms  9.437 ms
>  9.981 ms
>  3  core6a-rba-gi0-0-1.ip.isnet.net (168.209.100.202)  9.983 ms  9.458 ms
>  9.982 ms
>  4  core1b-rba-7600-gi1-0-10.ip.isnet.net (168.209.1.181)  9.983 ms  9.352
> ms  9.982 ms
>  5  168.209.161.202 (168.209.161.202)  169.978 ms  169.737 ms  169.882 ms
>  6  168.209.160.209 (168.209.160.209)  169.884 ms  169.863 ms  169.889 ms
>  7  core1a-dock-gi1-0-19-22.ip.isnet.net (168.209.161.161)  174.497 ms
>  174.354 ms  174.263 ms
>  8  core2b-dock-gi1-2.ip.isnet.net (168.209.246.66)  170.238 ms  170.227 ms
>  170.261 ms
>  9  ae0-1302-xcr1.lsw.cw.net (166.63.211.205)  174.375 ms  174.352 ms
>  174.257 ms
> 10  lon2-core.gigabiteth3-0.swip.net (195.66.224.87)  301.808 ms  218.958 ms
>  210.479 ms
> 11  ams17-core-1.pos15-0-0.swip.net (130.244.192.13)  178.263 ms  177.966 ms
>  177.877 ms
> 12  130.244.49.206 (130.244.49.206)  178.383 ms  178.476 ms  178.379 ms
> 13  ams16-core-1.gigabiteth13-1-0.swip.net (130.244.49.197)  182.626 ms
>  182.723 ms  182.879 ms
> 14  br01tc2.versatel.net (130.244.200.130)  179.246 ms  179.225 ms  179.513
> ms
> 15  * * *
> ^C
> #
>
> ie.  a host, in .za, on your ISP1's network, in 196/8, that works just fine.
> another host - in an adjoining datacentre, that follows the same network
> path, and is part of the same /15 advert, doesn't.
>
> (incidentally, the tcptraceroute is identical from a host that *doesn't*
> work).
>
> there is some measure of filtering, and/or some attempt at policy routing,
> that is broken on the return path.
>
> --n.
>