1

I have IPTABLES newly set up on my Debian Squeeze server and I have IP masquerading and port forwarding working successfully with it, however if I type into the URL bar my WAN IP or DynDNS hostname, I get a connection error. With previous consumer routers, if I had gone to http://[myhostname], it would load 10.0.0.3:80 as specified below. This works externally (tested using a 3G phone) but not internally (using any internal browser). This is the same for all forwarded ports. I'm trying to get port forwarding to work internally as well.

If anyone knows the correct incantation(s) for this, it'd be greatly appreciated. I've tried searching Google but am unsure of the correct search terms for the issue.

My configuration is as follows:

# Generated by iptables-save v1.4.8 on Thu Apr 14 15:58:27 2011
*mangle
:PREROUTING ACCEPT [1216168:676166344]
:INPUT ACCEPT [2375:260404]
:FORWARD ACCEPT [1213765:675875465]
:OUTPUT ACCEPT [1930:203384]
:POSTROUTING ACCEPT [1215695:676078849]
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu 
COMMIT
# Completed on Thu Apr 14 15:58:27 2011
# Generated by iptables-save v1.4.8 on Thu Apr 14 15:58:27 2011
*filter
:INPUT ACCEPT [2375:260404]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1930:203384]
-A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i eth0 -o ppp0 -j ACCEPT 
-A FORWARD -d 10.0.0.8/32 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.8/32 -p tcp -m tcp --dport 1723 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.8/32 -p udp -m udp --dport 1723 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 21 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 45631 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 56630 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -d 10.0.0.3/32 -p udp -m udp --dport 56630 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
COMMIT
# Completed on Thu Apr 14 15:58:27 2011
# Generated by iptables-save v1.4.8 on Thu Apr 14 15:58:27 2011
*nat
:PREROUTING ACCEPT [5529:468229]
:POSTROUTING ACCEPT [2335:258730]
:OUTPUT ACCEPT [21:1367]
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.8:80 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.3:22 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 1723 -j DNAT --to-destination 10.0.0.8:1723 
-A PREROUTING -i ppp0 -p udp -m udp --dport 1723 -j DNAT --to-destination 10.0.0.8:1723 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 21 -j DNAT --to-destination 10.0.0.3:21 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 45631 -j DNAT --to-destination 10.0.0.3:45631 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 56630 -j DNAT --to-destination 10.0.0.3:56630 
-A PREROUTING -i ppp0 -p udp -m udp --dport 56630 -j DNAT --to-destination 10.0.0.3:56630 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.3:22 
-A POSTROUTING -o ppp0 -j MASQUERADE 
COMMIT
# Completed on Thu Apr 14 15:58:27 2011
Bart De Vos
  • 17,761
  • 6
  • 62
  • 81
Michael
  • 11
  • 2

2 Answers2

3

I am not sure I can see the point of this. Normally this kind of setup is used if you have an internal resource that needs to be accessible internally and externally. Your external access is achieved by the port forwarding, and you have confirmed that this is working fine.

For internal access, you should rather use split DNS. This is a setup whereby your internal DNS server resolves the same names as your public DNS, but to internal IP addresses. This can be achieved by using either separate DNS servers or one DNS server with separate views for internal and external access.

Would that solve your problem?

wolfgangsz
  • 8,767
  • 3
  • 29
  • 34
0

That won't work. The reason has to do with how a packet traverses the netfilter/xtables tables and when routing takes place.

  1. Packet enters interface
  2. Packet got DNAT-ed, which, for packets coming from eth0, doesn't happen
  3. Packet got routed. In this case, it's routed to the ppp0 interface
  4. Because packet is destined to the router, it gets handled by the INPUT chain
  5. Packet passes INPUT chain, gets handled by the TCP stack
  6. Local port 80 is not open; packet is dropped

As you can see, the DNAT happens too early in the chain of events.

pepoluan
  • 4,918
  • 3
  • 43
  • 71