SMTP Port Forwarding Problem

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

No, the TCP packet reaches the router and the server.

If you telnet to the SMTP server on port 25 from another machine on the same LAN, everything works 100%?

If so, it sounds to me either the port forward is hosed (try deleting and recreatiing the rule on the NetGear), or possibly the NetGear router is hosed. Try factory resetting it, and reconfigure it from scratch. Also make sure it has the latest firmware.

ASKER

The inbound port forwarding is working ok. The request shows in the trace and is exactly equivalent to the trace on the system that works. It's the response to this request that doesn't traverse the router, presumably because if the ip checksum error.

From other research I'm starting to think this is a checksum offload issue. Anyone got any experience with that?

prashsax

Are you sure, your ACL on routers are correct.

Should your Server is sending packets with incorrect checksum, it won't be accessible from within the network.

Make sure you have applied ACL on one interface only of your router.

If not then you need to allow packets in both direction.

ASKER

It's a very simple ADSL broadband router. There is no ACL.

The netmon trace shows ip checksum = 0 on all ip packets from the server network adapter. It doesn't appear to be causing any problems for other devices within the local network.

prashsax

Checksum should not be 0.

Are you taking netmon trace on the server itself.

You need to give permission to port 25 that is being blocked by windows xp firewall or any other firewall you have on your system. Thats it
Reps

ASKER

The netmon trace is on the server. It's SBS2003, no firewall.

Using multiple IPs on this NIC?

Check this site for all your problems
www.portforward.com
Surely your problem will get resolved witin no time.

Reps
If you liked the above solution please appreciate my work by providing points
Thank you

ASKER

aseusainc , single IP on this NIC.

Reps, for the moment I'm working on the assumption that the ip checksum issue is the reason for the response not traversing the router, so I'd recommend you focus your efforts there if you want the points.

Here's a sample frame:
No. Time Source Destination Protocol Info
80 4.680664 192.168.0.100 194.116.174.122 TCP smtp > 50754 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0

Frame 80 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: 00:13:72:09:e1:3f, Dst: 00:0f:b5:cb:53:ea
Internet Protocol, Src Addr: 192.168.0.100 (192.168.0.100), Dst Addr: 194.116.174.122 (194.116.174.122)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 64
Identification: 0xfcaf (64687)
Flags: 0x00
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x0000 (incorrect, should be 0x0c0d)
Source: 192.168.0.100 (192.168.0.100)
Destination: 194.116.174.122 (194.116.174.122)
Transmission Control Protocol, Src Port: smtp (25), Dst Port: 50754 (50754), Seq: 0, Ack: 1, Len: 0
Source port: smtp (25)
Destination port: 50754 (50754)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 44 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 16384
Checksum: 0xed79 (correct)
Options: (24 bytes)
SEQ/ACK analysis

0000 00 0f b5 cb 53 ea 00 13 72 09 e1 3f 08 00 45 00 ....S...r..?..E.
0010 00 40 fc af 00 00 80 06 00 00 c0 a8 00 64 c2 74 .@...........d.t
0020 ae 7a 00 19 c6 42 8d ab da ab bd 42 ea 85 b0 12 .z...B.....B....
0030 40 00 ed 79 00 00 02 04 05 b4 01 03 03 00 01 01 @..y............
0040 08 0a 00 00 00 00 00 00 00 00 01 01 04 02 ..............

In your network connection right the connection got to tcp/ip properties enter the static ip , subnet mask, and default gateway and reboot computer.
Also put your router in DMZ mode and check whether now smpt socket gets a response. Also u can check this setting from a computer which is from an external network.

Reps

ASKER

Static ip , subnet mask, and default gateway are all set correctly and the server has been rebooted during the course of this investigation. I don't want to use DMZ mode as that will require configuring a firewall on the server.

ASKER

Ok, from other research it appears that checksum offload can cause checksums to appear incorrect in network traces. So that's a red herring.

To reiterate, inbound port forwarding is workingcorrectly on the DG834 and this frame arrives:

No. Time Source Destination Protocol Info
79 4.680664 194.116.174.122 192.168.0.100 TCP 50754 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1360 TSV=1841013042 TSER=0 WS=7

Frame 79 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: 00:0f:b5:cb:53:ea, Dst: 00:13:72:09:e1:3f
Internet Protocol, Src Addr: 194.116.174.122 (194.116.174.122), Dst Addr: 192.168.0.100 (192.168.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 60
Identification: 0x4bb6 (19382)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 54
Protocol: TCP (0x06)
Header checksum: 0xc70a (correct)
Source: 194.116.174.122 (194.116.174.122)
Destination: 192.168.0.100 (192.168.0.100)
Transmission Control Protocol, Src Port: 50754 (50754), Dst Port: smtp (25), Seq: 0, Ack: 0, Len: 0
Source port: 50754 (50754)
Destination port: smtp (25)
Sequence number: 0 (relative sequence number)
Header length: 40 bytes
Flags: 0x0002 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 5840
Checksum: 0x8287 (correct)
Options: (20 bytes)
Maximum segment size: 1360 bytes
SACK permitted
Time stamp: tsval 1841013042, tsecr 0
NOP
Window scale: 7 (multiply by 128)

The server responds with the following frame, but this does not traverse the router:

No. Time Source Destination Protocol Info
80 4.680664 192.168.0.100 194.116.174.122 TCP smtp > 50754 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0

Frame 80 (78 bytes on wire, 78 bytes captured)
Ethernet II, Src: 00:13:72:09:e1:3f, Dst: 00:0f:b5:cb:53:ea
Internet Protocol, Src Addr: 192.168.0.100 (192.168.0.100), Dst Addr: 194.116.174.122 (194.116.174.122)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 64
Identification: 0xfcaf (64687)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x0000 (incorrect, should be 0x0c0d)
Source: 192.168.0.100 (192.168.0.100)
Destination: 194.116.174.122 (194.116.174.122)
Transmission Control Protocol, Src Port: smtp (25), Dst Port: 50754 (50754), Seq: 0, Ack: 1, Len: 0
Source port: smtp (25)
Destination port: 50754 (50754)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 44 bytes
Flags: 0x0012 (SYN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 16384
Checksum: 0xed79 (correct)
Options: (24 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 0 (multiply by 1)
NOP
NOP
Time stamp: tsval 0, tsecr 0
NOP
NOP
SACK permitted
SEQ/ACK analysis

This starts to look to me like a router firmware issue. Anyone have any other thoughts?

have u tried DMZ

ASKER

I've already answered that. I don't want to use DMZ mode as that will require configuring a firewall on the server.

Lets back up and check the EASY things so as to determine WHERE the problem is. I asked this earlier, but didn't see a reply:

If you telnet to the SMTP server on port 25 from another machine on the same LAN, everything works 100%?

If so, it sounds to me either the port forward is hosed (try deleting and recreatiing the rule on the NetGear), or possibly the NetGear router is hosed. Try factory resetting it, and reconfigure it from scratch. Also make sure it has the latest firmware.

ASKER

>> If you telnet to the SMTP server on port 25 from another machine on the same LAN, everything works 100%?
Yes

>> Try factory resetting it, and reconfigure it from scratch. Also make sure it has the latest firmware.
I will try that when I get the opportunity at the client site. However it's a newly purchased and freshly configured router, so it would be surprising if that made a difference.

sure this is windows xp firewall issue as it blocking some specific ports.Allow ports in windows xp firewall .
Also try restoring your modem to factory setting and then portforward the specific port

try it

ASKER

ded9, windows xp isn't even involved here. The server is running SBS 2003 with no firewall. There is no modem, it's an ADSL router. All of this has been answered before.

The fact that you were able to telnet to an SMTP session from another PC on the same subnet lets us rule out the server, windows firewall, etc. The only other possibility here would be a subnet restriction on the SMTP service. Otherwise, the router is more than likely your culprit.

>>However it's a newly purchased and freshly configured router, so it would be surprising if that made a difference.

I use these $100 consumer level routers all the time in the field, NOTHING surprises me. They do the oddest things for absolutely NO reason at all. I feel your pain! Guess we'll wait until you are able to check the firmware and do a factory reset/reconfigure to see where this goes...

ASKER

Thanks. I've got another router which is known to work so if the reset doesn't solve it I'll swap that in. That should finally finger the culprit. I'll report back on Monday.

there must a restore factory default setting in a router try it

ASKER

I haven't forgotten this, but it looks like it's now going to be the weekend before I get a chance to reset and swap out the router.

ASKER

At the weekend I brought the server and router to my own premises. SMTP inbound all worked correctly. Turns out that the ISP is blocking SMTP as suggested in the very first response from aseusainc. Bizarrely the blocking only seems to affect the outbound response not the inbound request!

Thanks to all.