[SOLVED] problems opening ports to outside...(sometimes it works, sometimes not)

[#1]

I have configured various NAT routes through my TG585 (v7/fw8.2.6.5) supplied by Plusnet. I have one rule that I cannot get to work properly.
When I point it at certain internal IP addresses it doesn't work, whereas for another internal address on the same network it works fine.
Both addresses (the working one and the non-working ones) have servers listening on the appropriate port. I can test them internally with "telnet", they're fine.
It's like the router can't see the internal services properly but I am at a loss as to what to look for.
I'm setting the nats up like this (via CLI interface):

service host assign name="Mail Server (SMTP)" host=10.x.y.z

I should be able to access port 25 from outside but I can't.
The nodes in question are connected to the router with ethernet cable, this isn't going over wireless. There are no firewalls in the way (iptables -L shows everything as being accepted on the destination host). Netstat shows there is a service listening on the appropriate port and that service responds when accessed from LAN-side with it's internal IP address. If I use the above assign with a working internal address it works fine, so I am sure that I am using the correct command on the router.
I'm in the dark and wonder if anyone might be able to suggest anything that I can look at.
thanks.
Screenshots of the web admin pages attached.

[#2]

Just to clarify your statement.
From the outside world, you can access port 25 when directed to server A but not when directed to server B?
If that is true then it implies that server B has some restrictive impediment on that port when the connection is originated from the gateway. Does that server trust all connections to that port, no matter what source they come from?
Another possibility (seen on TG582n's) if the target machine is not configured to have a static ip address and the mapping is by ip address rather than device name, a change in dhcp ip address has been known to screw the mapping.

If port 25 is not accessible at all from an external connection, go double check the settings on the firewall on your PlusNET account. See connection settings on the portal

[#3]

Quote from: Townman

Just to clarify your statement. From the outside world, you can access port 25 when directed to server A but not when directed to server B?

Yes, that's right

Quote

If that is true then it implies that server B has some restrictive impediment on that port when the connection is originated from the gateway. Does that server trust all connections to that port, no matter what source they come from?

Yes, as far as I believe. It's a Linux box and I have checked its own iptables and they have not been configured to block anything. I am now doing a package comparison as I have no idea what it might be.

Quote

Another possibility (seen on TG582n's) if the target machine is not configured to have a static ip address and the mapping is by ip address rather than device name, a change in dhcp ip address has been known to screw the mapping.

The machines have static addresses, and the configuration is done by address (although the router does resolve those and displays hostnames on the web admin screen.

Quote

If port 25 is not accessible at all from an external connection, go double check the settings on the firewall on your PlusNET account. See connection settings on the portal

It is accessible if I point it at server A but not if i point it at server B. I've just been digging around the CLI and spotted this (which looks correct).

> nat tmpllist
Type Interface       Ifgroup  Outside Address                Inside Address                 Use
NAPT any             wan      0.0.0.1:25                     10.0.200.10:25                 1

[#4]

Quote from: starfry

It is accessible if I point it at server A but not if i point it at server B. I've just been digging around the CLI and spotted this (which looks correct). > nat tmpllist Type Interface       Ifgroup  Outside Address                Inside Address                 Use NAPT any             wan      0.0.0.1:25                     10.0.200.10:25                 1

Assigning a port forward rule does two thing's :-
a) It maps the route through NAT as above.
b) it also opens a pinhole through the routers firewall.
You can check this with the cli command
firewall rule list
Look under the chain "forward_host_service" to check if the correct pinhole firewall rule is present.
I strongly suspect this firewall pinhole sometimes fails to be created (or a obsolete one cleared) when the target device is on a static LAN IP.
Suggestions:
Place the devices on dynamic LAN IP addresses.
OR
Create your own two permanent firewall pinhole rules.

[#5]

[code]Thanks, that is useful. I can see that doing
[code]
service host assign name="Mail Server (SMTP)" host=10.0.200.10

causes two rules to be added to the chain

Nr.  Flags  Rule                                                        
4    CDE    map_6_25-25:... : accept           map_6_25-25:25-25 *.* > *.map_6_25-25:0A00C80A
5    CDE    map_17_25-25... : accept           map_17_25-25:25-25 *.* > *.map_17_25-25:0A00C80A

which, in longhand (firewall rule list chain=forward_host_service format=cli), is

firewall rule add chain=forward_host_service index=4 name=map_6_25-25:0A00C80A dstip=map_6_25-25:0A00C80A serv=map_6_25-25:25-25 log=disabled state=enabled action=accept
firewall rule add chain=forward_host_service index=5 name=map_17_25-25:0A00C80A dstip=map_17_25-25:0A00C80A serv=map_17_25-25:25-25 log=disabled state=enabled action=accept

And disabling (service host disable name="Mail Server (SMTP)") removes those rules.
I've tried work out what they mean. From the help, dstip is the name of the destination ip expression. Similarly "serv", the name of the service expression. I can only assume they're right as am not sure where to check them. I presume it's a label containing the protocol (6=tcp and 17=udp) port ranges in decmal and the destination IP in hex (all of which look correct). I presume these are dynamic rules (hence the D flag) and the names just describe what's going on. Perhaps there is nothing to cross reference them to.
I've also tried manually adding a rule without success

firewall rule add chain=forward_host_service name=smtp srcintf=wan dstip=10.0.200.10 serv=smtp log=enabled state=enabled action=accept

[/code][/code]

[#6]

Try opening all ports first as a test, once that's working then try fine tuning.

Quote

firewall rule add chain=forward_host_service index=1 name=Mailserv srcintf=wan dstip=10.0.200.10 state=enabled action=accept

Alternatively would it help to use a different port (465) for the second smtp server.
You could then leave both PF rules in place.
If you prefer the second smtp server to use port 25 lan side rather than 465 you could use port translation to change 465 outside port to 25 inside.

[#7]

Adding that rule made no difference. Whatever is going on has to do with port 25. I can create rules for other ports (e.g. I tried port 26 successfully). However I cannot get port 25 to work.
I have stripped things bare to remove anything that could be getting in the way. I've plugged the device directly into an ethernet port on the router so it isn't going through my separate switch. I have booted it from a "system resuce cd" and configured networking (I have tried both DHCP and static). I listen using the following command-line

nc -vlnp 25

I then try these from another machine

nc -vn 10.a.b.c 25 # works
nc -vn 212.x.y.z 25 # does not work
nc -vn 212.x.y.z 26 # works

It's like when I first used port 25, something got set up that has been remembered and that is causing things to break. I have no idea what that might be, however. I say this because configuring port 25 to the original IP works fine, even if I move that IP from machine A which has always worked, to machine B which didn't.
OKOKOK! I have fixed it.
I trawled through a settings backup file and found an explicit nat mapping for the IP address that worked. I think I added it when trying to work out, without documentation, how to add port mappings through the CLI. I posted about that a while back. Anyway, a rule got left behind that happened to be for the IP I was using at the time.
Roll forward to setting things up on another address following what I had discovered to be the correct way (using "service host" rules), that old nat rule started getting in the way. I've deleted it now and everything is working fine.  Normally, the "nat map" rules get created and destroyed automatically when the "service host" rule is created and destroyed so there is no need to create them manually. I discovered that before, just didn't notice I'd left a manual nat map in place. So, my fault!
The Speedtouch router could really do with a decent document describing how it works; there doesn't seem to be any book on the subject.
Anyway, thanks for all the suggestions - I am only happy that I have it working again, albeit at the cost of three days of my time 

[#8]

A result is always nice to have, even if the journey was frustrating.
Thank you for coming back to share the explanation and marking the thread solved.

[#9]

Glad you've fixed the problem and thanks for letting us know