From: Dan Ferris <dan@usrsbin.com>
To: netfilter@lists.netfilter.org
Subject: Re: 1:1 NAT Help
Date: Tue, 08 Aug 2006 09:46:05 -0600 [thread overview]
Message-ID: <44D8B1BD.90204@usrsbin.com> (raw)
In-Reply-To: <02BB8A4AC86C564C89C7F14CF98CE0C40127FE@knowledge.wizdom.nu>
That could be, however at the moment, we are using the standard
Redhat/CentOS iptables startup script. So I think those modules are there.
I can't work on those boxes again until next week, so I'll do more
fiddling then. :)
Dan
Sietse van Zanen wrote:
> Seems like a connection trackking problem than.
>
> Are you sure you have all the modules loaded: ip_conntrack.o etc.?
>
> try executing these commands (in your firewall script):
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
> modprobe ip_conntrack_nat
> modprobe ip_nat
> modprobe ip_nat_ftp
> modprobe iptable_nat
>
> -Sietse
>
> ________________________________
>
> From: netfilter-bounces@lists.netfilter.org on behalf of Dan Ferris
> Sent: Tue 08-Aug-06 14:37
> To: netfilter@lists.netfilter.org
> Subject: Re: 1:1 NAT Help
>
>
>
> Forwarding is on in /etc/sysctl.conf
>
> As far as I know the routing is correct. 10.2.253.21 lives off of eth1,
> and eth1 has a route for 10.2.0.0/255.255.0.0 (yes it sucks, I didn't
> set up the subnets).
>
> tcpdump shows traffic coming into both of the interfaces, which is why
> this problem is so frustrating. Oh yes, SNAT works fine. We can set up
> a ping from the box behind the firewall to ping the Internet gateway,
> and the ping will go through fine. We can see the replies to
> 204.184.20.221. :(
>
> Dan
>
> Sietse van Zanen wrote:
>
>> Then, is forwarding alllowed?
>> cat 1 > /proc/sys/net/ipv4/ip_forward
>>
>> And there is a correct route to 10.2.253.21?
>>
>>
>> If both answer to yes, what do you see when you tcpdump on your internal interface on host 10.2.253.21 and try to connect to 204.184.20.221 from the Internet?
>>
>> And what do you see when you tcpdump on your external interface for 204.184.20.221, is traffic reaching your firewall?
>>
>> -Sietse
>>
>> ________________________________
>>
>> From: netfilter-bounces@lists.netfilter.org on behalf of Dan Ferris
>> Sent: Tue 08-Aug-06 14:14
>> To: netfilter@lists.netfilter.org
>> Subject: Re: 1:1 NAT Help
>>
>>
>>
>> Yes, because I cleared all the rules and set everything to accept before
>> testing.
>>
>> Dan
>>
>> Sietse van Zanen wrote:
>>
>>
>>> Are you sure, you also allow the connection in the FORWARD chain of the filter table?
>>>
>>> iptables -i eth2 -d 10.2.253.21 -j ACCEPT
>>>
>>> -Sietse
>>>
>>> ________________________________
>>>
>>> From: netfilter-bounces@lists.netfilter.org on behalf of Dan Ferris
>>> Sent: Mon 07-Aug-06 20:56
>>> To: netfilter@lists.netfilter.org
>>> Subject: 1:1 NAT Help
>>>
>>>
>>>
>>> Dear List,
>>>
>>> I have search Google, and the list archives back to 2003 and have found
>>> little information about this particular problem.
>>>
>>> First I present to you two very simplified rules.
>>>
>>> iptables -A PREROUTING -i eth2 -d 204.184.20.221 -j DNAT --to 10.2.253.21
>>>
>>> and
>>>
>>> iptables -A POSTROUTING -o eth2 -s 10.2.253.21 -j SNAT --to 204.184.20.221
>>>
>>> Having never really delt with 1:1 NAT before, I thought this would "just
>>> work". However, it does not work. The SNAT rule works fine. The DNAT
>>> rule does not work at all. I don't even see packets hitting it.
>>>
>>> A few other pieces of information:
>>>
>>> 1. Proxy arp does not seem to be a problem. When I SSH to the external
>>> IP, I can see the ethernet frames coming into the ethernet interface.
>>>
>>> 2. I have tried doing: ip addr add 204.184.20.221 dev eth2 and it still
>>> won't work.
>>>
>>> We have an old POS box running Debian with Shorewall and kernel 2.4 that
>>> works perfectly with the 1:1 NAT rules. However, the friend I am
>>> helping does not want to use Shorewall, as she wishes to learn iptables
>>> the old fashioned way. The only difference between the old Debian
>>> firewall and the new one is the the new one is running CentOS and the
>>> 2.6 kernel.
>>> The old firewall that works has proxy arp turned off and rp_filter
>>> turned on. The new firewall has proxy arp turned off and rp_filter
>>> turned on.
>>>
>>> I'm really lost and I used to think I was decent at iptables. So if
>>> anybody can help it would be appreciated.
>>>
>>> Thank you!
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> --
>> What do you call a guy with no legs who is waterskiing?
>>
>>
>> Skip.
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> What do you call a guy with no legs who is waterskiing?
>
>
> Skip.
>
>
>
>
>
>
>
--
What do you call a man with no legs who is waterskiing?
Skip.
next prev parent reply other threads:[~2006-08-08 15:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-07 18:56 1:1 NAT Help Dan Ferris
2006-08-08 7:51 ` Sietse van Zanen
2006-08-08 12:14 ` Dan Ferris
2006-08-08 12:25 ` Sietse van Zanen
2006-08-08 12:37 ` Dan Ferris
2006-08-08 12:51 ` Sietse van Zanen
2006-08-08 15:46 ` Dan Ferris [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-08-08 14:43 Robert LeBlanc
2006-08-07 17:05 1:1 NAT help Dan Ferris
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=44D8B1BD.90204@usrsbin.com \
--to=dan@usrsbin.com \
--cc=netfilter@lists.netfilter.org \
/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