IP Forwarding works on local port but not a remote port

IP Forwarding works on local port but not a remote port

[Dan Daugherty]

Normally I wouldn't have a problem with this but I'm doing something a
bit different than I would normally do.
I have a RHEL5 server with one NIC that is being used as a router.  My
problem is that I can't seem to completely forward requests off of
this box using iptables.  If I specify a port redirection to a local
port, it works fine but when I specify forwarding that port to another
machine, it fails.  I think the request is being sent through but the
response isn't making it back to me.  I can have a clean iptables to
start and only need to execute one command to make the local forward
work and since I'm not technically using the machine as a gateway, I'm
not sure if all the INPUT, OUTPUT and FORWARD chain commands are
necessary.

10.117.1.205 is the server in question
10.117.1.203 is the server I am trying to forward to

Working command:
iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
10.117.1.205:22

Using telnet to test:
telnet 10.117.1.205 1524
Trying 10.117.1.205...
Connected to -----------.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

Failing command:
iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
10.117.1.203:1524

Telnet never completes:
telnet 10.117.1.205 1524
Trying 10.117.1.205...


Any help is appreciated.

Thanks,
Dan

Re: IP Forwarding works on local port but not a remote port

[Покотиленко Костик]

В Птн, 05/02/2010 в 10:47 -0500, Dan Daugherty пишет:
> Normally I wouldn't have a problem with this but I'm doing something a
> bit different than I would normally do.
> I have a RHEL5 server with one NIC that is being used as a router.  My
> problem is that I can't seem to completely forward requests off of
> this box using iptables.  If I specify a port redirection to a local
> port, it works fine but when I specify forwarding that port to another
> machine, it fails.  I think the request is being sent through but the
> response isn't making it back to me.  I can have a clean iptables to
> start and only need to execute one command to make the local forward
> work and since I'm not technically using the machine as a gateway, I'm
> not sure if all the INPUT, OUTPUT and FORWARD chain commands are
> necessary.
> 
> 10.117.1.205 is the server in question
> 10.117.1.203 is the server I am trying to forward to
> 
> Working command:
> iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
> 10.117.1.205:22
> 
> Using telnet to test:
> telnet 10.117.1.205 1524
> Trying 10.117.1.205...
> Connected to -----------.
> Escape character is '^]'.
> SSH-2.0-OpenSSH_4.3
> 
> Failing command:
> iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
> 10.117.1.203:1524
> 
> Telnet never completes:
> telnet 10.117.1.205 1524
> Trying 10.117.1.205...

The problem here is that no actual routing is being done because all
hosts are in the same IP net.

This is what happens:

1. You send request:           x.x.x.x:X         -> 10.117.1.205:1524
2. Server is doing DNAT:       x.x.x.x:X         -> 10.117.1.203:1524
3. 10.117.1.203 is responding: 10.117.1.203:1524 -> x.x.x.x:X
4. x.x.x.x doesn't expect packets from 10.117.1.203, because it was
initially connecting to 10.117.1.205 and drops the packet.

For this to work you should also do SNAT:

iptables -t nat -A POSTROUTING -o eth0 -d 10.117.1.203 -p tcp --dport
1524 -j SNAT --to-source 10.117.1.205

This way responce packets will go back to 10.117.1.205 and then to
sender:

1. You send request:           x.x.x.x:X         -> 10.117.1.205:1524
2. Server is doing DNAT:       x.x.x.x:X         -> 10.117.1.203:1524
3. Server is doing SNAT:       10.117.1.205:X    -> 10.117.1.203:1524
4. 10.117.1.203 is responding: 10.117.1.203:1524 -> 10.117.1.205:X
5. Server is doing unSNAT:     10.117.1.203:1524 -> x.x.x.x:X
6. Server is doing unDNAT:     10.117.1.205:1524 -> x.x.x.x:X
7. x.x.x.x gets legal responce 10.117.1.205:1524 -> x.x.x.x:X

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: IP Forwarding works on local port but not a remote port

[Dan Daugherty]

Thanks.  I tried adding the SNAT entry and it still fails the same
way.  I need to enable logging to see where the packets are still
being dropped.  I've never had to enable logging so I need to check
the docs and get some results.

2010/2/5 Покотиленко Костик <casper@meteor.dp.ua>
>
> В Птн, 05/02/2010 в 10:47 -0500, Dan Daugherty пишет:
> > Normally I wouldn't have a problem with this but I'm doing something a
> > bit different than I would normally do.
> > I have a RHEL5 server with one NIC that is being used as a router.  My
> > problem is that I can't seem to completely forward requests off of
> > this box using iptables.  If I specify a port redirection to a local
> > port, it works fine but when I specify forwarding that port to another
> > machine, it fails.  I think the request is being sent through but the
> > response isn't making it back to me.  I can have a clean iptables to
> > start and only need to execute one command to make the local forward
> > work and since I'm not technically using the machine as a gateway, I'm
> > not sure if all the INPUT, OUTPUT and FORWARD chain commands are
> > necessary.
> >
> > 10.117.1.205 is the server in question
> > 10.117.1.203 is the server I am trying to forward to
> >
> > Working command:
> > iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
> > 10.117.1.205:22
> >
> > Using telnet to test:
> > telnet 10.117.1.205 1524
> > Trying 10.117.1.205...
> > Connected to -----------.
> > Escape character is '^]'.
> > SSH-2.0-OpenSSH_4.3
> >
> > Failing command:
> > iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
> > 10.117.1.203:1524
> >
> > Telnet never completes:
> > telnet 10.117.1.205 1524
> > Trying 10.117.1.205...
>
> The problem here is that no actual routing is being done because all
> hosts are in the same IP net.
>
> This is what happens:
>
> 1. You send request:           x.x.x.x:X         -> 10.117.1.205:1524
> 2. Server is doing DNAT:       x.x.x.x:X         -> 10.117.1.203:1524
> 3. 10.117.1.203 is responding: 10.117.1.203:1524 -> x.x.x.x:X
> 4. x.x.x.x doesn't expect packets from 10.117.1.203, because it was
> initially connecting to 10.117.1.205 and drops the packet.
>
> For this to work you should also do SNAT:
>
> iptables -t nat -A POSTROUTING -o eth0 -d 10.117.1.203 -p tcp --dport
> 1524 -j SNAT --to-source 10.117.1.205
>
> This way responce packets will go back to 10.117.1.205 and then to
> sender:
>
> 1. You send request:           x.x.x.x:X         -> 10.117.1.205:1524
> 2. Server is doing DNAT:       x.x.x.x:X         -> 10.117.1.203:1524
> 3. Server is doing SNAT:       10.117.1.205:X    -> 10.117.1.203:1524
> 4. 10.117.1.203 is responding: 10.117.1.203:1524 -> 10.117.1.205:X
> 5. Server is doing unSNAT:     10.117.1.203:1524 -> x.x.x.x:X
> 6. Server is doing unDNAT:     10.117.1.205:1524 -> x.x.x.x:X
> 7. x.x.x.x gets legal responce 10.117.1.205:1524 -> x.x.x.x:X
>
> --
> Покотиленко Костик <casper@meteor.dp.ua>
>

Re: IP Forwarding works on local port but not a remote port

[Покотиленко Костик]

В Птн, 05/02/2010 в 13:13 -0500, Dan Daugherty пишет:
> Thanks.  I tried adding the SNAT entry and it still fails the same
> way.  I need to enable logging to see where the packets are still
> being dropped.  I've never had to enable logging so I need to check
> the docs and get some results.

First, check the rule counters with iptables -t nat -nvL
Then tcpdump on both 10.117.1.205 and 10.117.1.203.


> 2010/2/5 Покотиленко Костик <casper@meteor.dp.ua>
>         В Птн, 05/02/2010 в 10:47 -0500, Dan Daugherty пишет:
>         
>         > Normally I wouldn't have a problem with this but I'm doing
>         something a
>         > bit different than I would normally do.
>         > I have a RHEL5 server with one NIC that is being used as a
>         router.  My
>         > problem is that I can't seem to completely forward requests
>         off of
>         > this box using iptables.  If I specify a port redirection to
>         a local
>         > port, it works fine but when I specify forwarding that port
>         to another
>         > machine, it fails.  I think the request is being sent
>         through but the
>         > response isn't making it back to me.  I can have a clean
>         iptables to
>         > start and only need to execute one command to make the local
>         forward
>         > work and since I'm not technically using the machine as a
>         gateway, I'm
>         > not sure if all the INPUT, OUTPUT and FORWARD chain commands
>         are
>         > necessary.
>         >
>         > 10.117.1.205 is the server in question
>         > 10.117.1.203 is the server I am trying to forward to
>         >
>         > Working command:
>         > iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j
>         DNAT --to
>         > 10.117.1.205:22
>         >
>         > Using telnet to test:
>         > telnet 10.117.1.205 1524
>         > Trying 10.117.1.205...
>         > Connected to -----------.
>         > Escape character is '^]'.
>         > SSH-2.0-OpenSSH_4.3
>         >
>         > Failing command:
>         > iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j
>         DNAT --to
>         > 10.117.1.203:1524
>         >
>         > Telnet never completes:
>         > telnet 10.117.1.205 1524
>         > Trying 10.117.1.205...
>         
>         
>         The problem here is that no actual routing is being done
>         because all
>         hosts are in the same IP net.
>         
>         This is what happens:
>         
>         1. You send request:           x.x.x.x:X         ->
>         10.117.1.205:1524
>         2. Server is doing DNAT:       x.x.x.x:X         ->
>         10.117.1.203:1524
>         3. 10.117.1.203 is responding: 10.117.1.203:1524 -> x.x.x.x:X
>         4. x.x.x.x doesn't expect packets from 10.117.1.203, because
>         it was
>         initially connecting to 10.117.1.205 and drops the packet.
>         
>         For this to work you should also do SNAT:
>         
>         iptables -t nat -A POSTROUTING -o eth0 -d 10.117.1.203 -p tcp
>         --dport
>         1524 -j SNAT --to-source 10.117.1.205
>         
>         This way responce packets will go back to 10.117.1.205 and
>         then to
>         sender:
>         
>         1. You send request:           x.x.x.x:X         ->
>         10.117.1.205:1524
>         2. Server is doing DNAT:       x.x.x.x:X         ->
>         10.117.1.203:1524
>         3. Server is doing SNAT:       10.117.1.205:X    ->
>         10.117.1.203:1524
>         4. 10.117.1.203 is responding: 10.117.1.203:1524 ->
>         10.117.1.205:X
>         5. Server is doing unSNAT:     10.117.1.203:1524 -> x.x.x.x:X
>         6. Server is doing unDNAT:     10.117.1.205:1524 -> x.x.x.x:X
>         7. x.x.x.x gets legal responce 10.117.1.205:1524 -> x.x.x.x:X
>         
>         --
>         Покотиленко Костик <casper@meteor.dp.ua>
>         
> 
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: IP Forwarding works on local port but not a remote port

[Dan Daugherty]

I had to make some changes to the ultimate destination since the
machine I am trying to get to didn't have tcpdump and getting it for
solaris isn't worth it to me.  Since I know this is an iptables issue,
I'm good with using a different destination to test and then change it
in production.

Dictionary:
err.sfa.com is the machine from which I am testing. ip of 6.149
sethra is the router. ip of 1.205
vlad is the destination machine. ip of 1.206


Commands used on sethra:
iptables -F
iptables -F -t nat
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 1521 -j LOG
--log-prefix '**LOG PRE** '
iptables -t nat -A POSTROUTING -o eth0 -p tcp  -j LOG --log-prefix
'**LOG POST** '

iptables -t nat -A PREROUTING -p tcp --dport 1521 -i eth0 -j DNAT --to
10.117.1.206:1521
iptables -t nat -A POSTROUTING -o eth0 -d 10.117.1.206 -p tcp --dport
1521 -j SNAT --to-source 10.117.1.205

err:~ dan$ telnet 10.117.1.205 1521
Trying 10.117.1.205...
telnet: connect to address 10.117.1.205: Operation timed out
telnet: Unable to connect to remote host

packet counts
[root@sethra ~]# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 35405 packets, 42M bytes)
 pkts bytes target     prot opt in     out     source
destination
   22  1152 LOG        tcp  --  eth0   *       0.0.0.0/0
0.0.0.0/0           tcp dpt:1521 LOG flags 0 level 4 prefix `**LOG
PRE** '
   22  1152 DNAT       tcp  --  eth0   *       0.0.0.0/0
0.0.0.0/0           tcp dpt:1521 to:10.117.1.206:1521

Chain POSTROUTING (policy ACCEPT 428 packets, 39754 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 LOG        tcp  --  *      eth0    0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `**LOG POST** '
    0     0 SNAT       tcp  --  *      eth0    0.0.0.0/0
10.117.1.206        tcp dpt:1521 to:10.117.1.205

Chain OUTPUT (policy ACCEPT 471 packets, 48328 bytes)
 pkts bytes target     prot opt in     out     source
destination


Kernel logs:
Feb  5 14:01:27 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=13244 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:28 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=1431 DF PROTO=TCP
SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:29 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=21407 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:30 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=44931 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:31 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=17401 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:32 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=23430 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:34 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=34207 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:38 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=7366 DF PROTO=TCP
SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:01:46 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=36068 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:02:02 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=32933 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
Feb  5 14:02:34 sethra kernel: **LOG PRE** IN=eth0 OUT=
MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=32389 DF
PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0

TPCDUMP sethra
[root@sethra ~]# tcpdump -i eth0 'port 1521'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:01:27.126210 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
3,nop,nop,timestamp 635091437 0,sackOK,eol>
14:01:28.107814 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
3,nop,nop,timestamp 635091446 0,sackOK,eol>
14:01:29.108654 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
3,nop,nop,timestamp 635091456 0,sackOK,eol>
14:01:30.109676 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:01:31.110723 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:01:32.111917 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:01:34.113682 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:01:38.117485 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:01:46.125289 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:02:02.139805 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
14:02:34.169506 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>

11 packets captured
11 packets received by filter
0 packets dropped by kernel

TCPDUMP vlad
[root@vlad ~]# tcpdump -i eth0 'port 1521'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

Re: IP Forwarding works on local port but not a remote port

[Christoph Paasch]

Hi,

looks like the packets are not hitting the POSTROUTING-Hook. 

Are you sure that you have forwarding enabled in your kernel?
Check /proc/sys/net/ipv4/ip_forward

Or an iptables rule in the forwarding-chain?

Regards,
Christoph

On Fri 5 February 2010 wrote Dan Daugherty:
> I had to make some changes to the ultimate destination since the
> machine I am trying to get to didn't have tcpdump and getting it for
> solaris isn't worth it to me.  Since I know this is an iptables issue,
> I'm good with using a different destination to test and then change it
> in production.
> 
> Dictionary:
> err.sfa.com is the machine from which I am testing. ip of 6.149
> sethra is the router. ip of 1.205
> vlad is the destination machine. ip of 1.206
> 
> 
> Commands used on sethra:
> iptables -F
> iptables -F -t nat
> iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 1521 -j LOG
> --log-prefix '**LOG PRE** '
> iptables -t nat -A POSTROUTING -o eth0 -p tcp  -j LOG --log-prefix
> '**LOG POST** '
> 
> iptables -t nat -A PREROUTING -p tcp --dport 1521 -i eth0 -j DNAT --to
> 10.117.1.206:1521
> iptables -t nat -A POSTROUTING -o eth0 -d 10.117.1.206 -p tcp --dport
> 1521 -j SNAT --to-source 10.117.1.205
> 
> err:~ dan$ telnet 10.117.1.205 1521
> Trying 10.117.1.205...
> telnet: connect to address 10.117.1.205: Operation timed out
> telnet: Unable to connect to remote host
> 
> packet counts
> [root@sethra ~]# iptables -t nat -nvL
> Chain PREROUTING (policy ACCEPT 35405 packets, 42M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>    22  1152 LOG        tcp  --  eth0   *       0.0.0.0/0
> 0.0.0.0/0           tcp dpt:1521 LOG flags 0 level 4 prefix `**LOG
> PRE** '
>    22  1152 DNAT       tcp  --  eth0   *       0.0.0.0/0
> 0.0.0.0/0           tcp dpt:1521 to:10.117.1.206:1521
> 
> Chain POSTROUTING (policy ACCEPT 428 packets, 39754 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>     0     0 LOG        tcp  --  *      eth0    0.0.0.0/0
> 0.0.0.0/0           LOG flags 0 level 4 prefix `**LOG POST** '
>     0     0 SNAT       tcp  --  *      eth0    0.0.0.0/0
> 10.117.1.206        tcp dpt:1521 to:10.117.1.205
> 
> Chain OUTPUT (policy ACCEPT 471 packets, 48328 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
> 
> 
> Kernel logs:
> Feb  5 14:01:27 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=13244 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:28 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=1431 DF PROTO=TCP
> SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:29 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=21407 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:30 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=44931 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:31 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=17401 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:32 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=23430 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:34 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=34207 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:38 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=7366 DF PROTO=TCP
> SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:46 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=36068 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:02:02 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=32933 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:02:34 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=32389 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> 
> TPCDUMP sethra
> [root@sethra ~]# tcpdump -i eth0 'port 1521'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 14:01:27.126210 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
> 3,nop,nop,timestamp 635091437 0,sackOK,eol>
> 14:01:28.107814 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
> 3,nop,nop,timestamp 635091446 0,sackOK,eol>
> 14:01:29.108654 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
> 3,nop,nop,timestamp 635091456 0,sackOK,eol>
> 14:01:30.109676 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:31.110723 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:32.111917 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:34.113682 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:38.117485 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:46.125289 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:02:02.139805 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:02:34.169506 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 
> 11 packets captured
> 11 packets received by filter
> 0 packets dropped by kernel
> 
> TCPDUMP vlad
> [root@vlad ~]# tcpdump -i eth0 'port 1521'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
Christoph Paasch

Alcatel-Lucent
IP Development

www.rollerbulls.be
--

Re: IP Forwarding works on local port but not a remote port

[Покотиленко Костик]

В Птн, 05/02/2010 в 14:14 -0500, Dan Daugherty пишет:
> I had to make some changes to the ultimate destination since the
> machine I am trying to get to didn't have tcpdump and getting it for
> solaris isn't worth it to me.  Since I know this is an iptables issue,
> I'm good with using a different destination to test and then change it
> in production.
> 
> Dictionary:
> err.sfa.com is the machine from which I am testing. ip of 6.149
> sethra is the router. ip of 1.205
> vlad is the destination machine. ip of 1.206

Are you using /16 netmask?

> Commands used on sethra:
> iptables -F
> iptables -F -t nat
> iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 1521 -j LOG
> --log-prefix '**LOG PRE** '
> iptables -t nat -A POSTROUTING -o eth0 -p tcp  -j LOG --log-prefix
> '**LOG POST** '
> 
> iptables -t nat -A PREROUTING -p tcp --dport 1521 -i eth0 -j DNAT --to
> 10.117.1.206:1521
> iptables -t nat -A POSTROUTING -o eth0 -d 10.117.1.206 -p tcp --dport
> 1521 -j SNAT --to-source 10.117.1.205
> 
> err:~ dan$ telnet 10.117.1.205 1521
> Trying 10.117.1.205...
> telnet: connect to address 10.117.1.205: Operation timed out
> telnet: Unable to connect to remote host
> 
> packet counts
> [root@sethra ~]# iptables -t nat -nvL
> Chain PREROUTING (policy ACCEPT 35405 packets, 42M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>    22  1152 LOG        tcp  --  eth0   *       0.0.0.0/0
> 0.0.0.0/0           tcp dpt:1521 LOG flags 0 level 4 prefix `**LOG
> PRE** '
>    22  1152 DNAT       tcp  --  eth0   *       0.0.0.0/0
> 0.0.0.0/0           tcp dpt:1521 to:10.117.1.206:1521

22 connections (attempts) got DNATed.

> Chain POSTROUTING (policy ACCEPT 428 packets, 39754 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>     0     0 LOG        tcp  --  *      eth0    0.0.0.0/0
> 0.0.0.0/0           LOG flags 0 level 4 prefix `**LOG POST** '
>     0     0 SNAT       tcp  --  *      eth0    0.0.0.0/0
> 10.117.1.206        tcp dpt:1521 to:10.117.1.205

None of them got SNATed. Why? Should they go out through eth0? Try to
remove "-o eth0".

Also do you have ip.forwarding enabled (sysctl -a | grep forward")?

Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?

> Chain OUTPUT (policy ACCEPT 471 packets, 48328 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
> 
> 
> Kernel logs:
> Feb  5 14:01:27 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=13244 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:28 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=1431 DF PROTO=TCP
> SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:29 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=64 TOS=0x10 PREC=0x00 TTL=64 ID=21407 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:30 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=44931 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:31 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=17401 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:32 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=23430 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:34 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=34207 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:38 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=7366 DF PROTO=TCP
> SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:01:46 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=36068 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:02:02 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=32933 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb  5 14:02:34 sethra kernel: **LOG PRE** IN=eth0 OUT=
> MAC=00:26:b9:3f:89:f9:00:17:f2:c8:24:8a:08:00 SRC=10.117.6.149
> DST=10.117.1.205 LEN=48 TOS=0x10 PREC=0x00 TTL=64 ID=32389 DF
> PROTO=TCP SPT=62981 DPT=1521 WINDOW=65535 RES=0x00 SYN URGP=0
> 
> TPCDUMP sethra
> [root@sethra ~]# tcpdump -i eth0 'port 1521'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 14:01:27.126210 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
> 3,nop,nop,timestamp 635091437 0,sackOK,eol>
> 14:01:28.107814 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
> 3,nop,nop,timestamp 635091446 0,sackOK,eol>
> 14:01:29.108654 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,nop,wscale
> 3,nop,nop,timestamp 635091456 0,sackOK,eol>
> 14:01:30.109676 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:31.110723 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:32.111917 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:34.113682 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:38.117485 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:01:46.125289 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:02:02.139805 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 14:02:34.169506 IP err.sfa.com.62981 > sethra.sfa.com.ncube-lm: S
> 3593594566:3593594566(0) win 65535 <mss 1460,sackOK,eol>
> 
> 11 packets captured
> 11 packets received by filter
> 0 packets dropped by kernel
> 
> TCPDUMP vlad
> [root@vlad ~]# tcpdump -i eth0 'port 1521'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

vlad didn't even got requests, this is either routing or forwarding
problem.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: IP Forwarding works on local port but not a remote port

[Dan Daugherty]

> Are you using /16 netmask?
No, I just took the 10.117 part off the ip's to shorten the message.
>
>
> None of them got SNATed. Why? Should they go out through eth0? Try to
> remove "-o eth0".
Removed it and no change
>
> Also do you have ip.forwarding enabled (sysctl -a | grep forward")?
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.lo.forwarding = 0
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.forwarding = 1

>
> Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
>
Negative, but the command from sethra fails immediately with nothing
showing in the logs

There has also been mention of a FORWARD chain being necessary.  I
haven't done anything outside of the commands listed in this thread.

Re: IP Forwarding works on local port but not a remote port

[Dan Daugherty]

Forgot to mention I'm on a Redhat Enterprise Linux 5 box with the
stock kernel.  Tried to compile my own and the build fails
immediately.  I assumed that since I can route requests locally, the
kernel was compiled properly for iptables.

On Fri, Feb 5, 2010 at 3:01 PM, Dan Daugherty <rescue@ddaniscool.com> wrote:
>> Are you using /16 netmask?
> No, I just took the 10.117 part off the ip's to shorten the message.
>>
>>
>> None of them got SNATed. Why? Should they go out through eth0? Try to
>> remove "-o eth0".
> Removed it and no change
>>
>> Also do you have ip.forwarding enabled (sysctl -a | grep forward")?
> net.ipv6.conf.eth0.forwarding = 0
> net.ipv6.conf.default.forwarding = 0
> net.ipv6.conf.all.forwarding = 0
> net.ipv6.conf.lo.forwarding = 0
> net.ipv4.conf.eth0.mc_forwarding = 0
> net.ipv4.conf.eth0.forwarding = 1
> net.ipv4.conf.lo.mc_forwarding = 0
> net.ipv4.conf.lo.forwarding = 1
> net.ipv4.conf.default.mc_forwarding = 0
> net.ipv4.conf.default.forwarding = 1
> net.ipv4.conf.all.mc_forwarding = 0
> net.ipv4.conf.all.forwarding = 1
>
>>
>> Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
>>
> Negative, but the command from sethra fails immediately with nothing
> showing in the logs
>
> There has also been mention of a FORWARD chain being necessary.  I
> haven't done anything outside of the commands listed in this thread.
>

Re: IP Forwarding works on local port but not a remote port

[Dan Daugherty]

Well, I ended up figuring it out.  I swear I tried this early on
because this is how I wanted it to work in the first place.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
10.117.1.203:1524

That is all I needed.  The machine sits behind another firewall so
none of the other chains are necessary.  Thanks for all the help.

Dan

On Fri, Feb 5, 2010 at 3:04 PM, Dan Daugherty <rescue@ddaniscool.com> wrote:
> Forgot to mention I'm on a Redhat Enterprise Linux 5 box with the
> stock kernel.  Tried to compile my own and the build fails
> immediately.  I assumed that since I can route requests locally, the
> kernel was compiled properly for iptables.
>
> On Fri, Feb 5, 2010 at 3:01 PM, Dan Daugherty <rescue@ddaniscool.com> wrote:
>>> Are you using /16 netmask?
>> No, I just took the 10.117 part off the ip's to shorten the message.
>>>
>>>
>>> None of them got SNATed. Why? Should they go out through eth0? Try to
>>> remove "-o eth0".
>> Removed it and no change
>>>
>>> Also do you have ip.forwarding enabled (sysctl -a | grep forward")?
>> net.ipv6.conf.eth0.forwarding = 0
>> net.ipv6.conf.default.forwarding = 0
>> net.ipv6.conf.all.forwarding = 0
>> net.ipv6.conf.lo.forwarding = 0
>> net.ipv4.conf.eth0.mc_forwarding = 0
>> net.ipv4.conf.eth0.forwarding = 1
>> net.ipv4.conf.lo.mc_forwarding = 0
>> net.ipv4.conf.lo.forwarding = 1
>> net.ipv4.conf.default.mc_forwarding = 0
>> net.ipv4.conf.default.forwarding = 1
>> net.ipv4.conf.all.mc_forwarding = 0
>> net.ipv4.conf.all.forwarding = 1
>>
>>>
>>> Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
>>>
>> Negative, but the command from sethra fails immediately with nothing
>> showing in the logs
>>
>> There has also been mention of a FORWARD chain being necessary.  I
>> haven't done anything outside of the commands listed in this thread.
>>
>

Re: IP Forwarding works on local port but not a remote port

[Christoph Paasch]

MASQUERADE is just the same as SNAT. The only difference is, that it takes its 
src-ipaddress dynamically from the interface.

It should work also with the rule
iptables -t nat -A POSTROUTING -j SNAT --to-source [ip of your router]

In fact, iptables recommends using SNAT, when you have a static ip address on 
your router.

In fact, in the previous posts we all messed up a little bit with the changing 
IP-addresses and ports that were not consistent.


On Fri 5 February 2010 wrote Dan Daugherty:
> Well, I ended up figuring it out.  I swear I tried this early on
> because this is how I wanted it to work in the first place.
> 
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> iptables -t nat -A PREROUTING -p tcp --dport 1524 -i eth0 -j DNAT --to
> 10.117.1.203:1524
> 
> That is all I needed.  The machine sits behind another firewall so
> none of the other chains are necessary.  Thanks for all the help.
> 
> Dan
> 
> On Fri, Feb 5, 2010 at 3:04 PM, Dan Daugherty <rescue@ddaniscool.com> wrote:
> > Forgot to mention I'm on a Redhat Enterprise Linux 5 box with the
> > stock kernel.  Tried to compile my own and the build fails
> > immediately.  I assumed that since I can route requests locally, the
> > kernel was compiled properly for iptables.
> >
> > On Fri, Feb 5, 2010 at 3:01 PM, Dan Daugherty <rescue@ddaniscool.com> 
wrote:
> >>> Are you using /16 netmask?
> >>
> >> No, I just took the 10.117 part off the ip's to shorten the message.
> >>
> >>> None of them got SNATed. Why? Should they go out through eth0? Try to
> >>> remove "-o eth0".
> >>
> >> Removed it and no change
> >>
> >>> Also do you have ip.forwarding enabled (sysctl -a | grep forward")?
> >>
> >> net.ipv6.conf.eth0.forwarding = 0
> >> net.ipv6.conf.default.forwarding = 0
> >> net.ipv6.conf.all.forwarding = 0
> >> net.ipv6.conf.lo.forwarding = 0
> >> net.ipv4.conf.eth0.mc_forwarding = 0
> >> net.ipv4.conf.eth0.forwarding = 1
> >> net.ipv4.conf.lo.mc_forwarding = 0
> >> net.ipv4.conf.lo.forwarding = 1
> >> net.ipv4.conf.default.mc_forwarding = 0
> >> net.ipv4.conf.default.forwarding = 1
> >> net.ipv4.conf.all.mc_forwarding = 0
> >> net.ipv4.conf.all.forwarding = 1
> >>
> >>> Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
> >>
> >> Negative, but the command from sethra fails immediately with nothing
> >> showing in the logs
> >>
> >> There has also been mention of a FORWARD chain being necessary.  I
> >> haven't done anything outside of the commands listed in this thread.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
Christoph Paasch

Alcatel-Lucent
IP Development

www.rollerbulls.be
--

Re: IP Forwarding works on local port but not a remote port

[Покотиленко Костик]

В Птн, 05/02/2010 в 15:04 -0500, Dan Daugherty пишет:
> Forgot to mention I'm on a Redhat Enterprise Linux 5 box with the
> stock kernel.  Tried to compile my own and the build fails
> immediately.  I assumed that since I can route requests locally, the
> kernel was compiled properly for iptables.

To do what you are trying to do iptables are not enough.

> On Fri, Feb 5, 2010 at 3:01 PM, Dan Daugherty <rescue@ddaniscool.com> wrote:
> >> Are you using /16 netmask?
> > No, I just took the 10.117 part off the ip's to shorten the message.
> >>
> >>
> >> None of them got SNATed. Why? Should they go out through eth0? Try to
> >> remove "-o eth0".
> > Removed it and no change
> >>
> >> Also do you have ip.forwarding enabled (sysctl -a | grep forward")?
> > net.ipv6.conf.eth0.forwarding = 0
> > net.ipv6.conf.default.forwarding = 0
> > net.ipv6.conf.all.forwarding = 0
> > net.ipv6.conf.lo.forwarding = 0
> > net.ipv4.conf.eth0.mc_forwarding = 0
> > net.ipv4.conf.eth0.forwarding = 1
> > net.ipv4.conf.lo.mc_forwarding = 0
> > net.ipv4.conf.lo.forwarding = 1
> > net.ipv4.conf.default.mc_forwarding = 0
> > net.ipv4.conf.default.forwarding = 1
> > net.ipv4.conf.all.mc_forwarding = 0
> > net.ipv4.conf.all.forwarding = 1
> >
> >>
> >> Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
> >>
> > Negative, but the command from sethra fails immediately with nothing
> > showing in the logs
> >
> > There has also been mention of a FORWARD chain being necessary.  I
> > haven't done anything outside of the commands listed in this thread.
> >
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: IP Forwarding works on local port but not a remote port

[Christoph Paasch]

On Fri 5 February 2010 wrote Dan Daugherty:
> > Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
> 
> Negative, but the command from sethra fails immediately with nothing
> showing in the logs
As far as I can see, your destination-machine (vlad) has it's IP ending with 
1.206 (your previous mail) .

Try a simple ping to vlad from sethra.
If this is not working show us the output of "ip route".

Cheers,
Christoph

--
Christoph Paasch

Alcatel-Lucent
IP Development

www.rollerbulls.be
--

Re: IP Forwarding works on local port but not a remote port

[Покотиленко Костик]

В Птн, 05/02/2010 в 15:01 -0500, Dan Daugherty пишет:
> > Are you using /16 netmask?
> No, I just took the 10.117 part off the ip's to shorten the message.
> >
> >
> > None of them got SNATed. Why? Should they go out through eth0? Try to
> > remove "-o eth0".
> Removed it and no change
> >
> > Also do you have ip.forwarding enabled (sysctl -a | grep forward")?
> net.ipv6.conf.eth0.forwarding = 0
> net.ipv6.conf.default.forwarding = 0
> net.ipv6.conf.all.forwarding = 0
> net.ipv6.conf.lo.forwarding = 0
> net.ipv4.conf.eth0.mc_forwarding = 0
> net.ipv4.conf.eth0.forwarding = 1
> net.ipv4.conf.lo.mc_forwarding = 0
> net.ipv4.conf.lo.forwarding = 1
> net.ipv4.conf.default.mc_forwarding = 0
> net.ipv4.conf.default.forwarding = 1
> net.ipv4.conf.all.mc_forwarding = 0
> net.ipv4.conf.all.forwarding = 1
> 
> >
> > Can you reach 10.117.1.205:1521 from sethra (telnet 10.117.1.205 1521)?
> >
> Negative, but the command from sethra fails immediately with nothing
> showing in the logs

You should first be able to reach it from sethra.

What it says when it fails?

What is output of "ifconfig; route -n"? It seems like sethra can't make
path to 10.117.1.205 or nothing sits there on 1521 port.

> There has also been mention of a FORWARD chain being necessary.  I
> haven't done anything outside of the commands listed in this thread.

Check chain policies not to be DROP. Show output of "iptables-save".

-- 
Покотиленко Костик <casper@meteor.dp.ua>