Re: iptables question
On Mar 9, 2007, at 18:14, David A. Long wrote: I have a small sequential block of public IP addresses I would like to filter through to matching servers on my private network. The iptables NETMAP target looks like it might do this efficiently (combined with a lot of other rules to filter out unwanted traffic). Just a tip - I've done something similar many years back, but I think it wasn't with NETMAP - there might be another way - but: I do remember banging my head against some 3Com switches for a couple hours of following docs and fiddling with rules before I realized both IP Forwarding and Proxy ARP had to be turned on for it to work. And then the first examples I tried in the initial five minutes worked straight away. That was back when we were figuring out if we should have a firewall for our Internet connection. These days I just setup a pfsense box and use 1:1 NAT for this kind of setup. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 New Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: iptables question
On 3/9/07, David A. Long <[EMAIL PROTECTED]> wrote:
The iptables NETMAP target looks like it might do this
efficiently ...
It may. I don't know if NETMAP also invokes the connection tracking
and packet rewriting stuff or not. If not, then protocols which need
to know about their own addresses (e.g., FTP) may get tripped up.
But I cannot understand how the "source" IP address gets rewritten in the
packet with this target. The NETMAP documentation is very terse and never
mentions the source address, only the destination.
Well, I've never used NETMAP myself, but my guess is that the
address which should be rewritten (source or destination) would be
implied by whether the NETMAP target is being invoked from the
PREROUTING or POSTROUTING table. If NETMAP is being invoked from the
PREROUTING table, then it should rewrite the destination address, so
the kernel can route the packet appropriately. If NETMAP is being
invoked from the POSTROUTING table, then it should rewrite the source
address, so the other end sees the correct sender.
If I'm right, the "--to" switch does not mean "host this packet is
going TO", but rather, "network to map traffic TO". So your second
rule says to rewrite ${LAN_NET}.0/24 to ${WAN_NET}.0/24.
Yah?
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
iptables question
I have a small sequential block of public IP addresses I would like to
filter through to matching servers on my private network. The iptables
NETMAP target looks like it might do this efficiently (combined with a
lot of other rules to filter out unwanted traffic). But I cannot
understand how the "source" IP address gets rewritten in the packet with
this target. The NETMAP documentation is very terse and never mentions
the source address, only the destination. Can someone provide an
example or explanation of how NETMAP can be used both to remap traffic
addressed to the server addresses, *and* remap the source address of
returning traffic? Here is what I have now, but the second rule does
not make sense to me (even though I wrote it):
iptables -t nat -A PREROUTING -i ${WAN_IFACE} -d ${WAN_NET}.0/24 -j NETMAP --to
${LAN_NET}.0/24
iptables -t nat -A POSTROUTING -o ${WAN_IFACE} -s ${LAN_NET}.0/24 -j NETMAP
--to ${WAN_NET}.0/24
Thanks,
-dl
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: iptables question for the experts
Ben, thanks for the script! It turns out that some modules were installed but the lack of ip_conntrack_ftp.ko being installed made all the difference! I hadn't realized that iptables could have kernel module dependencies, I learned something new! Dan ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: iptables question for the experts
Chris Brenton wrote: On Mon, 2006-07-17 at 18:19 -0400, Dan Coutu wrote: I am expecting that following line opens traffic to the remote server on whatever port passive mode ftp chooses to use: eeek! Scary rules. ;-p Just to verify, these are the rules on the client which is connecting to the server, correct? If so try this: insmod ip_conntrack_ftp.ko insmod ip_nat_ftp.ko iptables -A OUTPUT -p tcp -d --dport 25 -j ACCEPT iptables -A INPUT -m state --state ESTABLISH,RELATED -j ACCEPT note you don't need to install ip_nat_ftp unless you have boxes sitting behind this one. HTH, Chris This is in fact on the client machine, not the server. There's no NAT involved. I'll see where this gets me... Thanks! Dan ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: iptables question for the experts
On Tue, 2006-07-18 at 15:26 -0400, Chris Brenton wrote: > > iptables -A OUTPUT -p tcp -d --dport 25 -j ACCEPT Dooh! Change that to be: iptables -A OUTPUT -p tcp -d --dport 21 -j ACCEPT ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: iptables question for the experts
On Mon, 2006-07-17 at 18:19 -0400, Dan Coutu wrote: > > I am expecting that following line opens traffic to the remote server on > whatever port passive mode ftp chooses to use: eeek! Scary rules. ;-p Just to verify, these are the rules on the client which is connecting to the server, correct? If so try this: insmod ip_conntrack_ftp.ko insmod ip_nat_ftp.ko iptables -A OUTPUT -p tcp -d --dport 25 -j ACCEPT iptables -A INPUT -m state --state ESTABLISH,RELATED -j ACCEPT note you don't need to install ip_nat_ftp unless you have boxes sitting behind this one. HTH, Chris ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: iptables question for the experts
On 7/18/06, Steven W. Orr <[EMAIL PROTECTED]> wrote:
Also, don't you need to have ip_conntrack loaded to deal with ftp?x
Various modules definitely need to be loaded. What I'm not sure
about is which ones are loaded automatically by the kernel/iptables
and which ones need to be loaded explicitly (be it "by hand" or via
shell script or whatever). Rather then keep track of that, I just
explicitly load them all in my firewall scripts. :)
#
function load_modules () {
local i moddir
echo "Loading kernel modules for firewall..."
for i in ip_tables iptable_filter ip_conntrack iptable_nat ; do
if ! grep -q "$i" /proc/modules ; then
modprobe $i
fi
done
moddir="/lib/modules/$(uname -r)/kernel/net/ipv4/netfilter"
for i in $moddir/ip_conntrack_* ; do
i=$( basename $i .o)
if ! grep -q "$i" /proc/modules ; then
modprobe $i
fi
done
for i in $moddir/ip_nat_* ; do
i=$( basename $i .o)
if ! grep -q "$i" /proc/modules ; then
modprobe $i
fi
done
#
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: iptables question for the experts
On Tuesday, Jul 18th 2006 at 07:09 -0400, quoth Ben Scott: =>On 7/17/06, Dan Coutu <[EMAIL PROTECTED]> wrote: =>> I am expecting that following line opens traffic to the remote server on =>> whatever port passive mode ftp chooses to use: => => Are these iptables rules on the FTP client, or the FTP server? => => I will assume the FTP server. I'll also assume 64.39.2.176 is the =>IP address of the FTP client. => => You will need two rules on the FTP server: => =>iptables -A INPUT -s 64.39.2.176 -p tcp --dport ftp -j ACCEPT =>iptables -A INPUT -s 64.39.2.176 -m state --state ESTABLISHED,RELATED -j =>ACCEPT => => In the above, the first rule allows your FTP client to open =>connections to the FTP server on the port reserved for the FTP control =>channel (TCP/21). The second rule allows any traffic which is (1) =>part of an already-established session or (2) related to an =>already-established session. "Session" is a magic word implemented by =>the various "conntrack" modules. In this case, that will be all the =>rest of the FTP traffic. => =>> I am expecting that following line opens traffic to the remote server on =>> whatever port passive mode ftp chooses to use: =>> =>> -A INPUT -s 64.39.2.176 -p tcp -m tcp --sport 1:65535 --dport 1:65535 -m \ =>> state --state ESTABLISHED -j ACCEPT => => Your expectations are wrong. ;-) => => First, not specifying a port does the same thing as specifying a =>range of 1:65535 (but not specifying a port might be more efficient). =>So we can rewrite that as: => =>-A INPUT -s 64.39.2.176 -p tcp -m state --state ESTABLISHED -j ACCEPT => => The above just allows packets which are part of already-established =>sessions through. It is generally used when your rule sets are very =>specific about initial connection attempts. This isn't one of those. =>:) In particular, the FTP data channel is not considered an =>"established" session, but a "related" one. See above. => =>> The next line immediately follows it in the iptables config file and it =>> allows basic ftp traffic in the first place. =>> =>> -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT => => The FTP control channel will come from an ephemeral source port. =>The *destination* port will be 21. => => Further, since you specify ESTABLISHED, that rule will only apply to =>sessions which are *already* connected. There's nothing to allow =>initial connects in the first place. => =>> When I use wget to test the fetch operation I see it establish a =>> connection successfully, go into passive mode, and time out. => => If wget is actually making a successful control connection to the =>FTP server, I'd remove your two FTP rules, and try again. It may =>behave the same. Your firewall may be not be doing what you think it =>is doing. => =>-- Ben Also, don't you need to have ip_conntrack loaded to deal with ftp?x ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: iptables question for the experts
On 7/17/06, Dan Coutu <[EMAIL PROTECTED]> wrote: I am expecting that following line opens traffic to the remote server on whatever port passive mode ftp chooses to use: Are these iptables rules on the FTP client, or the FTP server? I will assume the FTP server. I'll also assume 64.39.2.176 is the IP address of the FTP client. You will need two rules on the FTP server: iptables -A INPUT -s 64.39.2.176 -p tcp --dport ftp -j ACCEPT iptables -A INPUT -s 64.39.2.176 -m state --state ESTABLISHED,RELATED -j ACCEPT In the above, the first rule allows your FTP client to open connections to the FTP server on the port reserved for the FTP control channel (TCP/21). The second rule allows any traffic which is (1) part of an already-established session or (2) related to an already-established session. "Session" is a magic word implemented by the various "conntrack" modules. In this case, that will be all the rest of the FTP traffic. I am expecting that following line opens traffic to the remote server on whatever port passive mode ftp chooses to use: -A INPUT -s 64.39.2.176 -p tcp -m tcp --sport 1:65535 --dport 1:65535 -m \ state --state ESTABLISHED -j ACCEPT Your expectations are wrong. ;-) First, not specifying a port does the same thing as specifying a range of 1:65535 (but not specifying a port might be more efficient). So we can rewrite that as: -A INPUT -s 64.39.2.176 -p tcp -m state --state ESTABLISHED -j ACCEPT The above just allows packets which are part of already-established sessions through. It is generally used when your rule sets are very specific about initial connection attempts. This isn't one of those. :) In particular, the FTP data channel is not considered an "established" session, but a "related" one. See above. The next line immediately follows it in the iptables config file and it allows basic ftp traffic in the first place. -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT The FTP control channel will come from an ephemeral source port. The *destination* port will be 21. Further, since you specify ESTABLISHED, that rule will only apply to sessions which are *already* connected. There's nothing to allow initial connects in the first place. When I use wget to test the fetch operation I see it establish a connection successfully, go into passive mode, and time out. If wget is actually making a successful control connection to the FTP server, I'd remove your two FTP rules, and try again. It may behave the same. Your firewall may be not be doing what you think it is doing. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
iptables question for the experts
I'm trying to troubleshoot what seems like it ought to be a simple iptables configuration. Here's the goal here: The server has a cron job that periodically uses ftp to fetch from a remote server an updated script to be used for doing backups. ftp is configured to use passive mode. I am expecting that following line opens traffic to the remote server on whatever port passive mode ftp chooses to use: -A INPUT -s 64.39.2.176 -p tcp -m tcp --sport 1:65535 --dport 1:65535 -m state --state ESTABLISHED -j ACCEPT The next line immediately follows it in the iptables config file and it allows basic ftp traffic in the first place. -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT When I use wget to test the fetch operation I see it establish a connection successfully, go into passive mode, and time out. Any idea what I'm doing wrong here? Thanks in advance, Dan ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: IPTables question
Where is the UAS running that the client is communicating too? The re-INVITE should have the same call-id, branch and to tag, so I'm thinking the UAS will pick up the IP change which is ultimately what you want. Ed Bill McGonigle wrote: On Dec 15, 2005, at 18:22, [EMAIL PROTECTED] wrote: When the IP address on the client changes, it sends a reinvite to the NAT box to tell it what the new IP address is. I don't know SIP beyond a magazine article, but at a higher level it sounds like you need something like a mod_conntrack_sip that would know how to parse the SIP reinvite and tweak the proper kernel entries accordingly. Or you might be able to find a module that can track the DHCP conversations similarly. That being older it's more likely to exist and would be protocol-generic, so probably better. Either way, it sounds like you probably need a kernel module that understands that kind of traffic and can adjust the NAT tables. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: IPTables question
On Dec 15, 2005, at 18:22, [EMAIL PROTECTED] wrote: When the IP address on the client changes, it sends a reinvite to the NAT box to tell it what the new IP address is. I don't know SIP beyond a magazine article, but at a higher level it sounds like you need something like a mod_conntrack_sip that would know how to parse the SIP reinvite and tweak the proper kernel entries accordingly. Or you might be able to find a module that can track the DHCP conversations similarly. That being older it's more likely to exist and would be protocol-generic, so probably better. Either way, it sounds like you probably need a kernel module that understands that kind of traffic and can adjust the NAT tables. -Bill - Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: IPTables question
-- Original message -- From: Ben Scott <[EMAIL PROTECTED]> > On 12/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > The clients IP address can change from, say, 192.168.0.3 to 192.168.0.54 > > (or > any other > > address, I'm just making these up), but the session to the server needs to > > be > maintained. > > I don't think that is possible with "off the shelf" IPTables. I'm > think you could do it with enough custom code, but not easily. I thought that there was a way to do this with the state and connection tracking. But, like I said, I haven't touched iptables in quite some time. > > The NAT box will know when the ip address changes and what the new > address is. > > How does it know that? Through session signaling (possibly a SIP re-invite). > Can you explain what the situation is? Possibly. Well, I can explain it to the best of my ability, that it. I don't completely understand some of this myself, so. There is client software running on the client system. That software talks to an app running on the NAT box. It uses SIP (I think) for signaling. When the IP address on the client changes, it sends a reinvite to the NAT box to tell it what the new IP address is. So, if the client, 192.168.1.3, is trying to connect to a web site, it goes to www.foo.com port 80. The client initiates it using port 1234 (making this up). It goes through the NAT box, and the NAT box sends is out using it's external fixed address, 10.0.0.10 on port 5505. www.foo.com talks to the NAT box 10.0.0.10 on port 5505. So when the client changes IP addresses, www.foo.com needs to continue talking to the NAT box on port 5505, and the NAT box needs to send the packets to 192.168.1.4 now. I hope that makes it more possible :-) Thanks, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: IPTables question
On 12/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The clients IP address can change from, say, 192.168.0.3 to 192.168.0.54 (or > any other > address, I'm just making these up), but the session to the server needs to be > maintained. I don't think that is possible with "off the shelf" IPTables. I'm think you could do it with enough custom code, but not easily. > The NAT box will know when the ip address changes and what the new address is. How does it know that? Can you explain what the situation is? -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
IPTables question
Hi All, This is a rather odd question, and I'm not even sure that it is possible, but I'll give it a try. I need to figure out a way to maintain a session through a NAT box when the client changes the IP address. So, the situation looks like this: Clients--> iptables/NAT> Server 192.168.0.x int. 192.168.0.1 ext. 10.0.0.2 65.202.222.2 The clients IP address can change from, say, 192.168.0.3 to 192.168.0.54 (or any other address, I'm just making these up), but the session to the server needs to be maintained. The NAT box will know when the ip address changes and what the new address is. Is there a facility within iptables to handle this sort of thing? I admit that I am really rusty with iptables, not having used it for over a year TIA, Kenny ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
