From: "Покотиленко Костик" <casper@meteor.dp.ua>
To: Dan Daugherty <rescue@ddaniscool.com>
Cc: netfilter@vger.kernel.org
Subject: Re: IP Forwarding works on local port but not a remote port
Date: Fri, 05 Feb 2010 21:50:39 +0200 [thread overview]
Message-ID: <1265399439.3910.29.camel@casper.meteor.dp.ua> (raw)
In-Reply-To: <81ed8b881002051114o520f3f92l2fd46ece17900edb@mail.gmail.com>
В Птн, 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>
next prev parent reply other threads:[~2010-02-05 19:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-05 15:47 IP Forwarding works on local port but not a remote port Dan Daugherty
2010-02-05 17:11 ` Покотиленко Костик
2010-02-05 18:16 ` Dan Daugherty
[not found] ` <81ed8b881002051013n5f020a3fladfda4a5f33aa625@mail.gmail.com>
2010-02-05 18:24 ` Покотиленко Костик
2010-02-05 19:14 ` Dan Daugherty
2010-02-05 19:37 ` Christoph Paasch
2010-02-05 19:50 ` Покотиленко Костик [this message]
2010-02-05 20:01 ` Dan Daugherty
2010-02-05 20:04 ` Dan Daugherty
2010-02-05 20:46 ` Dan Daugherty
2010-02-05 21:10 ` Christoph Paasch
2010-02-05 20:53 ` Покотиленко Костик
2010-02-05 20:51 ` Christoph Paasch
2010-02-05 20:52 ` Покотиленко Костик
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1265399439.3910.29.camel@casper.meteor.dp.ua \
--to=casper@meteor.dp.ua \
--cc=netfilter@vger.kernel.org \
--cc=rescue@ddaniscool.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox