# Port Forwarding problem...

## jsosic

I'm going slightly mad about this one....

I've stripped down my iptables script to the bone, and yet, it refuses to work... I hope some of you have ideas, I don't know what will I do with this one...

```
IPTABLES='/sbin/iptables'

/bin/echo "1" > /proc/sys/net/ipv4/ip_forward

EXITIF="eth2"

INTIF0="eth0"

INTIF1="eth1"

$IPTABLES -F

$IPTABLES -t nat -F

$IPTABLES -t mangle -F

$IPTABLES -t nat -A POSTROUTING -o $EXITIF -j MASQUERADE

$IPTABLES -t nat -A PREROUTING -i $EXITIF -p tcp --dport 22 -j DNAT --to 192.168.1.113

$IPTABLES -t nat -A PREROUTING -i $EXITIF -p tcp --dport 9176 -j DNAT --to 192.168.1.113
```

I have 2 computers, one with iptables is my home router, other is my gentoo box. Masquearade works great, but Destination NAT seems to be giving me pretty hard time  :Sad: 

If I try to "ssh mydnsname", router responds and not my homebox. Also nmap shows following if I try to scan 9176 (valknut port):

```
# nmap -sT -p 9176 myip

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-30 00:56 CET

Interesting ports on CPE-217-198-100-152.dynamic.cable-kbn.ticnet.HR (217.198.10

0.152):                                                                         PORT     STATE  SERVICE

9176/tcp closed unknown

Nmap finished: 1 IP address (1 host up) scanned in 5.144 seconds
```

I'm really going mad... What can be the problem? Is it some kind of a iptables and/or netfilter bug?!? I'm running 2.6.11.12-grsec kernel at the time...

----------

## gerdesj

Just a suggestion, grab fwbuilder.  It will enable you to better visualize what is going on. especially when you start getting more sophisticated with your rules.  Good web site with lots of examples.

Cheers

Jon

 *jsosic wrote:*   

> I'm going slightly mad about this one....
> 
> I've stripped down my iptables script to the bone, and yet, it refuses to work... I hope some of you have ideas, I don't know what will I do with this one...
> 
> ```
> ...

 

----------

## Jeremy_Z

Maybe you could post the result of both :

```

iptables -vnL

iptables -t nat -vnL

```

And try replacing --to by --to-destination ?

----------

## nielchiano

 *jsosic wrote:*   

> If I try to "ssh mydnsname"

 

from where do you try this?

because if you try this from INSIDE the router, it's normal that it doesn't work: you just asked to DNAT everything from the external interface.

----------

## dj_farid

I seem to have a similar problem:

https://forums.gentoo.org/viewtopic-t-428207.html

Let me know in either of our threads, if you find a solution.

----------

## jsosic

nielchiano was right... Actual problem was I was nmaping and sshing from within my router... Everything works just fine, it's my brain that doesn't work  :Smile: 

I've scanned my computer with online port scanner, and it shows everything as it should be. My friend can log in to my ssh, from external interface and that's it!

Also, --to is the same thing as --to-destination.

One more thing, I hate GUI stuff, there is only one true way for configuring iptables, and it's manually writing a bash script  :Smile: 

----------

## nielchiano

 *jsosic wrote:*   

> nielchiano was right... Actual problem was I was nmaping and sshing from within my router... 

 

 :Smile:  I had the same problem some time ago... only I needed it to work from the inside too... which sucks, since you need to do 3 NAT's to get it to work...

----------

## ShALLaX

Care to explain how you got it working internally too?  I'm trying to figure this out at the moment!

Thank you.

----------

## nielchiano

 *ShALLaX wrote:*   

> Care to explain how you got it working internally too?  I'm trying to figure this out at the moment!

 

I have an exam tomorrow, and it's 11PM over here. I'll post the very quick steps. If you need more, just ask and I'll answer after the exams...

you'll have to DNAT from external (which you already do)

you'll need to DNAT AND SNAT from internal, else it won't work. if you want to know why, wait till after the exams  :Wink: 

----------

## ShALLaX

I understand - it's exam season for me too.  Yes, I would very much like for you to elaborate.  I'm currently using a small internal DNS server to redirect to the internal IP addresses which I find horribly inelegant.

Good luck tomorrow!

----------

## nielchiano

 *ShALLaX wrote:*   

> I understand - it's exam season for me too.  Yes, I would very much like for you to elaborate.  I'm currently using a small internal DNS server to redirect to the internal IP addresses which I find horribly inelegant.
> 
> Good luck tomorrow!

 

thx... it went well! Still have one on friday, but I need a little distraction...

the theory:

when you do a NAT, you always do it on both directions: if you change the to-address is a packet, you must make sure that you change the "from" address in any reply to that as well.

If you don't, the machine will receive a packet from a "strange host" and discard it.

In the external case it all works out: I connect to your external IP, the router secretly changes the destination-IP (DNAT) from your public IP to your internal web-server-ip. The web-server answers, the router secretly changes the source IP (masquerades, kind of SNAT) from the web-server-ip to the public IP again. everything works fine

however, if you want it to work internaly by just doing DNAT, you get the following situation: (i'll put IP addresses on them to make it easyer)

10.0.0.2, a client, connects to the external IP 11.0.0.1. Since it's external, it passes it on to the router, 10.0.0.1.

the router checks it's IP tables, sees that any packet with destination 11.0.0.1 has to be DNAT-ed to 10.0.0.3 (the web-server). he passes the packet out, back on the network it came from, but this time with an altered destination.

your web-server receives the packet, and replies to it. The reply is, of course, send to the "source address" of the request, i.e. 10.0.0.2.

Now the client, 10.0.0.2, receives a packet from 10.0.0.3, which he never talked to, so he discards that packet.

what should happen is:

the router changes the destination to the web server (DNAT) AND changes the source-address to his own adderss 10.0.0.1 (SNAT).

When the web-server replies, he will reply to the "source address", which is, in this case, the router.

the router gets the packet back, recognizes that it's part of a NAT that he did, and changes the IP's back to the form 10.0.0.2 expect them (i.e. source=11.0.0.1 (PUBLIC!), destination=10.0.0.2).

this way, 10.0.0.2 gets a packet from the IP it originaly send a request to, and everything works fine.

I don't have time to write/check a working setup, but I think you can figure it out yourself.

as already reported: you need DNAT from external, and both DNAT and SNAT from internal.

If you're stuck, you'll have to wait till friday afternoon (in europe) = end of my exams!

----------

## ShALLaX

Hrm, I think I'll need you to expand further on this.  I tried doing some SNATting, but that didnt help.

----------

## nielchiano

 *ShALLaX wrote:*   

> Hrm, I think I'll need you to expand further on this.  I tried doing some SNATting, but that didnt help.

 

these lines made it work here:

```

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dest public.ip --dport 22 -j DNAT --to-destination ssh.server:22

iptables -t nat -A PREROUTING -i eth0 -p tcp --dest public.ip --dport 22 -j DNAT --to-destination ssh.server:22

iptables -t nat -A POSTROUTING -p tcp --source internal.ips/24 --dest ssh.server --dport 22 -j SNAT --to-source internal.ip.of.router
```

if it doens't work, give me the output of 

```
iptables -vnL

iptables -t nat -vnL

ifconfig

route

```

and give some explanation which interface is connected to where. You may change your IP's if you're concerned with privacy, but be sure to keep subnets and stuff.

----------

