<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/12/2015 20:27, Anurag Bhatia
wrote:<br>
</div>
<blockquote
cite="mid:CAJ0+aXbu_TCy6xSBvZq9FDX+-WeZXb6i+ysq0k0bC3WD-K+JWg@mail.gmail.com"
type="cite">
<div>Your reply is bit confusing from part below since I own and
manage the test server (server7) not Jasim's server. :)</div>
<div><br>
</div>
<div>Keep in mind I am not running <a moz-do-not-send="true"
href="http://btraccl.net">btraccl.net</a> DNS servers. It's
Jasim who is having trouble. But yes I get hints you are sharing
for troubleshooting. :) </div>
<div><br>
</div>
</blockquote>
The confusion is entirely mine; I apologise for spreading it :-)<br>
<br>
So, what you can do on your side is:<br>
<br>
# in one window<br>
sudo tcpdump -i eth0 -nn -s0 -v host 103.9.185.229 or icmp<br>
# in another window<br>
dig @<a href="http://103.9.185.229" target="_blank">103.9.185.229</a>
<a href="http://btraccl.net" target="_blank">btraccl.net</a> mx<br>
<br>
Probably you will just see your outbound packets, but you *might*
see ICMP "Admin Prohibited" coming back. If so, that's hard evidence
of filtering, and will show exactly where the filtering is taking
place, which is extremely useful.<br>
<br>
If you don't mind sharing your IP address (privately with Jasim if
you prefer), then:<br>
<br>
1. Jasim can try a traceroute to that address and see if it works.
(Presumably it does, because of the end-to-end ping and traceroute
you see)<br>
<br>
2. Jasim can run tcpdump on the DNS server and look for traffic from
your IP while you send a query, and see if the query arrives or not.
It might be that the inbound packets are arriving, but the responses
are being filtered.<br>
<br>
I think you're right it's most likely a broken firewall somewhere,
but I *have* seen ISPs intentionally block UDP 53/123 in a misguided
attempt to "protect" their customers, and/or to force them to use
the ISP's own caching resolver (for example because they are doing
anti-porn or anti-warez filtering in DNS)<br>
<br>
Another outside possibility is that there is a layer2 bonded pair of
links in the path, and one of the links is faulty. These typically
use a hash of source/destination IP and port to decide which link to
send the packet over. This could mean that ICMP is taking one path
but UDP port 53 taking a different one.<br>
<br>
Out of interest: if you do "telnet 103.9.185.227 25" from server7,
does it connect successfully? This would imply that if Jasim gets a
proper secondary DNS, the mail would flow happily (and also more
strongly points the finger at UDP port 53 filtering)<br>
<br>
I see:<br>
<br>
$ telnet 103.9.185.227 25<br>
Trying 103.9.185.227...<br>
Connected to 103.9.185.227.<br>
Escape character is '^]'.<br>
<< long delay here; implies reverse DNS lookup problems at the
server side >><br>
220-cp1.btraccl.net ESMTP Exim 4.86 #2 Thu, 24 Dec 2015 02:55:58
+0600<br>
220-We do not authorize the use of this system to transport
unsolicited,<br>
220 and/or bulk e-mail.<br>
<br>
Regards,<br>
<br>
Brian.<br>
<br>
P.S. For comparison, here's traceroute from a VM in the UK. The last
few hops are the same as you see, but in this case it's not going
via airtel.in. That *might* be where the problem is occuring.<br>
<br>
$ traceroute -w1 103.9.185.229<br>
traceroute to 103.9.185.229 (103.9.185.229), 30 hops max, 60 byte
packets<br>
1 213-138-103-3.no-reverse-dns-set.uk0.bigv.io (213.138.103.3)
0.578 ms 0.575 ms 0.612 ms<br>
2 te3-4.cr2.man.bytemark.co.uk (91.223.58.64) 0.811 ms 0.952 ms
1.073 ms<br>
3 te0-0-1-0.cr4.man.bytemark.co.uk (91.223.58.132) 6.914 ms
7.160 ms 7.248 ms<br>
4 te0-0-1-2.cr1.lon.bytemark.co.uk (91.223.58.27) 7.090 ms
te0-0-2-2.cr1.lon.bytemark.co.uk (91.223.58.25) 7.129 ms
te0-0-1-2.cr1.lon.bytemark.co.uk (91.223.58.27) 7.215 ms<br>
5 81.25.207.213 (81.25.207.213) 7.186 ms 7.194 ms 7.198 ms<br>
6 ae-7.r23.londen03.uk.bb.gin.ntt.net (129.250.6.54) 28.439 ms
12.812 ms 41.834 ms<br>
7 ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85) 8.765 ms
8.743 ms 8.735 ms<br>
8 ae-3.r00.sngpsi05.sg.bb.gin.ntt.net (129.250.7.21) 194.383 ms
190.415 ms 190.434 ms<br>
9 ae-3.r00.sngpsi05.sg.bb.gin.ntt.net (129.250.7.21) 191.934 ms
194.400 ms 192.356 ms<br>
10 116.51.28.130 (116.51.28.130) 243.758 ms
103-16-152-25-noc.bsccl.com (103.16.152.25) 241.136 ms 239.398 ms<br>
11 103-16-152-25-noc.bsccl.com (103.16.152.25) 241.584 ms
103-16-152-33-noc.bsccl.com (103.16.152.33) 241.600 ms
103-16-152-25-noc.bsccl.com (103.16.152.25) 239.196 ms<br>
12 103-16-155-26-noc.bsccl.com (103.16.155.26) 255.071 ms
103-16-152-33-noc.bsccl.com (103.16.152.33) 243.217 ms 241.485 ms<br>
13 103-16-155-26-noc.bsccl.com (103.16.155.26) 256.580 ms 256.585
ms po1-ar1-bn1-dh.equitel.com.bd (103.9.186.66) 259.161 ms<br>
14 po1-ar1-bn1-dh.equitel.com.bd (103.9.186.66) 257.245 ms
103.9.186.130 (103.9.186.130) 246.590 ms 248.499 ms<br>
15 103.9.186.130 (103.9.186.130) 248.612 ms 249.879 ms
103.9.185.229 (103.9.185.229) 246.982 ms<br>
<br>
</body>
</html>