On 02/01/2008, at 4:11 AM, Robert Moskowitz wrote:

I spent much of the past 24 hours trying to find out how to set up iptables for firewall routing WITHOUT NATing. Could not find anything.

*boggle* Is it really that hard?

## Clear up whatever is in there at the moment. iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -t nat -F POSTROUTING

## Accept anything related to existing connections iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

## I want to allow incoming port 80 to 1.2.3.4 iptables -A FORWARD -i ppp0 -d 1.2.3.4 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

## I want to allow incoming port 123 (ntp) to 1.2.3.6 iptables -A FORWARD -i ppp0 -d 1.2.3.6 -p udp -m udp --dport 123 -j ACCEPT

## Lets block ALL other incoming things iptables -A INPUT -j DROP iptables -A FORWARD -j DROP

There you go. That's a very basic firewall using iptables in about 3 minutes :)

-- Steven Haigh

Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897

Thanks I will read this through a bit later. Perhaps I was making more of it than needed, but my attempts were not working. And all I was trying for at first was to allow SSH through.

Steven Haigh wrote:

On 02/01/2008, at 4:11 AM, Robert Moskowitz wrote:

...

I spent much of the past 24 hours trying to find out how to set up iptables for firewall routing WITHOUT NATing. Could not find anything.

*boggle* Is it really that hard?

## Clear up whatever is in there at the moment. iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -t nat -F POSTROUTING

## Accept anything related to existing connections iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

## I want to allow incoming port 80 to 1.2.3.4 iptables -A FORWARD -i ppp0 -d 1.2.3.4 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

## I want to allow incoming port 123 (ntp) to 1.2.3.6 iptables -A FORWARD -i ppp0 -d 1.2.3.6 -p udp -m udp --dport 123 -j ACCEPT

## Lets block ALL other incoming things iptables -A INPUT -j DROP iptables -A FORWARD -j DROP

There you go. That's a very basic firewall using iptables in about 3 minutes :)

-- Steven Haigh

Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Christopher Chan wrote:

...

I spent much of the past 24 hours trying to find out how to set up iptables for firewall routing WITHOUT NATing. Could not find anything.

Eh? You just need to enable ip forwarding to enable routing. After that, it is put up the firewall rules as is necessary, build the appropriate routing tables on the firewall box and the boxes on the intranet(s).

iptables does not handle routing.

No, but iptables controls what is allowed to route, or it seems when you read the tutorials on iptables. I know about routing, Comer taught me, and I reviewed Stevens book. I know about firewalls; Belovin and I go back quite a ways. But configuring software to do what **I** want, well that is were the car hits the brick wall. As Belovin would say, "Here be Dragons."

Those little words, "put up the firewall rules as necessary" are equivalent to "and magic happens here."

I tried it. I had everything open. Then I blocked everything. Then I set up a rule to allow SSH in to eth0 and out eth1 (and the other way). At least I thought that was what the rules said, but no SSH connectivity through the firewall. That was when I realized that I had not found the necessary incantation, and I had already shot most of tuesday.

Up and running. I can understand what shorewall rules are saying. And I can see the results.

On Thursday 03 January 2008 12:37:56 Christopher Chan wrote:

Too bad you missed the documentation on netfilter then. It would have told you that the INPUT chain controls what comes to the box, the OUTPUT chain what originates from the box and the FORWARD chain what goes through the box.

You would have needed a rule in FORWARD to allow ssh connections through the box. The rules in the INPUT and OUTPUT chains would have zero effect on connections going through.

It might also help if we put a rule that will log what happens for troubleshooting. Put these lines in the last of your rules (pls mind the word wrap): iptables -A INPUT -m limit --limit 2/m --limit-burst 2 -j LOG --log-prefix '** INPUT DROP ** ' iptables -A OUTPUT -m limit --limit 2/m --limit-burst 2 -j LOG --log-prefix '** OUTPUT DROP ** ' iptables -A FORWARD -m limit --limit 2/m --limit-burst 2 -j LOG --log-prefix '** FORWARD DROP ** '

We can now see the result in /var/log/messages HTH,

Robert Moskowitz wrote:

qsm wrote:

...

maybe shorewall can do your live so easy.....

It does not support the rtl8150 chipset. That is what the I have in the way of USB ethernet dongles.

Which is another reason to go with a Centos based solution when you need to put something up as you go.

Which is how I have shorewall/shoreline working . . . .

[tkb@nutube ~]$ cat /etc/redhat-release CentOS release 5 (Final)

[tkb@nutube ~]$ rpm -qi shorewall Name : shorewall Relocations: (not relocatable) Version : 4.0.2 Vendor: Invoca Systems Release : 3 Build Date: Mon Aug 20 09:03:41 2007 Install Date: Mon Aug 20 09:05:25 2007 Build Host: nutube Group : System Environment/Base Source RPM: shorewall-4.0.2-3.src.rpm Size : 483558 License: GPL Signature : (none) Packager : Simon Matter simon.matter@invoca.ch URL : http://www.shorewall.net/ Summary : Shoreline Firewall is an iptables-based firewall for Linux systems Description : The Shoreline Firewall, more commonly known as "Shorewall", is a Netfilter (iptables) based firewall that can be used on a dedicated firewall system, a multi-function gateway/router/server or on a standalone GNU/Linux system.

Shorewall offers two alternative firewall compilers, shorewall-perl and shorewall-shell. The shorewall-perl compiler is suggested for new installed systems and shorewall-shell is provided for backwards compability and smooth legacy system upgrades because shorewall perl is not fully compatible with all legacy configurations.

On 03/01/2008, at 3:34 PM, Robert Moskowitz wrote:

Christopher Chan wrote:

...

...

I spent much of the past 24 hours trying to find out how to set up iptables for firewall routing WITHOUT NATing. Could not find anything.

Eh? You just need to enable ip forwarding to enable routing. After that, it is put up the firewall rules as is necessary, build the appropriate routing tables on the firewall box and the boxes on the intranet(s).

iptables does not handle routing.

No, but iptables controls what is allowed to route,

I think this is where you are getting confused and causing yourself issues. iptables has ZERO effect on what is allowed to route. It is a simple YES or NO as to if it should be allowed to pass or be filtered.

or it seems when you read the tutorials on iptables. I know about routing, Comer taught me, and I reviewed Stevens book. I know about firewalls; Belovin and I go back quite a ways. But configuring software to do what **I** want, well that is were the car hits the brick wall. As Belovin would say, "Here be Dragons."

Those little words, "put up the firewall rules as necessary" are equivalent to "and magic happens here."

It's actually not magical at all... Work with the mindset of "I want to allow X, Y, and Z, then deny everything else". This translates easily into iptables rules -j ACCEPT and then your last rule (or policy) should be a deny/drop/reject.

I tried it. I had everything open. Then I blocked everything. Then I set up a rule to allow SSH in to eth0 and out eth1 (and the other way). At least I thought that was what the rules said, but no SSH connectivity through the firewall. That was when I realized that I had not found the necessary incantation, and I had already shot most of tuesday.

Again, you are using the wrong mindset here... You rule would translate to: iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -d my.ssh.server.ip.here -p tcp -m state -- state NEW -m tcp --dport 22 -j ACCEPT iptables -A FORWARD -j DROP

This allows you to put PER HOST restrictions on what you want to do. If you want to do it on a per interface basis, then you will have the same rules for every host in your subnet. Easy, but not ideal.

To break down that rule into bitesized chunks for learning: -A FORWARD = adds this rule to the forwarding chain - as this will pass through us. -i eth0 = if the traffic comes in on eth0 -d my.ssh.server.ip.here = the destination of where the traffic will end up -p tcp = this rule only applies to the tcp protocol -m state --state NEW = We'll allow the SYN packet so that the rest will be accepted by a RELATED,ESTABLISHED rule. -m tcp = part of the stateful matching off the top of my head --dport = this rule only applies to things heading to port 22 (our earlier TCP flag will make sure we only act on tcp/22 traffic). -j ACCEPT = allow the traffic to pass.

As an exercise for the reader, write down a rule that would accept traffic from eth0, and destined for a web server on 1.2.3.4. You should notice that the rules will be pretty much identical. You would insert this rule somewhere after the related/established, and somewhere before the -j DROP rule.

Now keep in mind that iptables is a VERY simple beast and will apply the first rule that matches! Consider the following: iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp -d 1.2.3.4 -m state --state NEW -m tcp --dport 22 -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --dport 22 -j DROP

What would happen here, is that an incoming request for ssh to 1.2.3.4 would be accepted by rule #2, but the rule inspection would never make it to rule #3 to be dropped - so take care in the ordering of your rules.

Up and running. I can understand what shorewall rules are saying. And I can see the results.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- Steven Haigh

Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897

On Thu, January 3, 2008 8:18 am, Robert Moskowitz wrote:

Steven Haigh wrote:

...

On 03/01/2008, at 3:34 PM, Robert Moskowitz wrote:

...

Christopher Chan wrote:

...

...

I spent much of the past 24 hours trying to find out how to set up iptables for firewall routing WITHOUT NATing. Could not find anything.

Eh? You just need to enable ip forwarding to enable routing. After that, it is put up the firewall rules as is necessary, build the appropriate routing tables on the firewall box and the boxes on the intranet(s).

iptables does not handle routing.

No, but iptables controls what is allowed to route,

I think this is where you are getting confused and causing yourself issues. iptables has ZERO effect on what is allowed to route. It is a simple YES or NO as to if it should be allowed to pass or be filtered.

I have been tested as having a significant language usage problem, and am working on it. 'what is allowed to route', was a poor choice of wording. What you wrote above is much closer to what I wanted to say.

ip src/dest is used for routing decisions by the kernel. The IP state machine (check the RFC or any decent TCP/IP textbook) is really quite simple. But iptables sticks its nose into the center of that state machine and can mangle addresses to change how packets flow through the machine, or just simplely yank packets right out of the machine with a simple NO (drop).

So in my mind's eye of the IP state machine (my MSU CPS 410 prof was death on state machines; turn in a perfectly executing assignment without one and there went half your grade. See HIP for its state machine) is dictated by iptables as to what it is allowed to route.

...

...

Those little words, "put up the firewall rules as necessary" are equivalent to "and magic happens here."

It's actually not magical at all... Work with the mindset of "I want to allow X, Y, and Z, then deny everything else". This translates easily into iptables rules -j ACCEPT and then your last rule (or policy) should be a deny/drop/reject.

That is exactly what I tried to do. I just used the wrong bit of pixie dust (during some of the 'heated' IPsec meeting debates one fellow would try to sneak up a speaker 'that just did not get it' and sprinkle some glitter on them. He had labeled his tube of glitter as 'security pixie dust').

If you are interested in learning how iptables work, I suggest reading this book:

Linux Firewalls, Second Edition by Robert L. Ziegler ISBN 0-7357-1099-6

It covers everything from packet filtering concepts to practical examples.

Marko

Marko A. Jennings wrote:

On Thu, January 3, 2008 8:18 am, Robert Moskowitz wrote:

...

Steven Haigh wrote:

...

On 03/01/2008, at 3:34 PM, Robert Moskowitz wrote:

...

Christopher Chan wrote:

...

...

I spent much of the past 24 hours trying to find out how to set up iptables for firewall routing WITHOUT NATing. Could not find anything.

Eh? You just need to enable ip forwarding to enable routing. After that, it is put up the firewall rules as is necessary, build the appropriate routing tables on the firewall box and the boxes on the intranet(s).

iptables does not handle routing.

No, but iptables controls what is allowed to route,

I think this is where you are getting confused and causing yourself issues. iptables has ZERO effect on what is allowed to route. It is a simple YES or NO as to if it should be allowed to pass or be filtered.

I have been tested as having a significant language usage problem, and am working on it. 'what is allowed to route', was a poor choice of wording. What you wrote above is much closer to what I wanted to say.

ip src/dest is used for routing decisions by the kernel. The IP state machine (check the RFC or any decent TCP/IP textbook) is really quite simple. But iptables sticks its nose into the center of that state machine and can mangle addresses to change how packets flow through the machine, or just simplely yank packets right out of the machine with a simple NO (drop).

So in my mind's eye of the IP state machine (my MSU CPS 410 prof was death on state machines; turn in a perfectly executing assignment without one and there went half your grade. See HIP for its state machine) is dictated by iptables as to what it is allowed to route.

...

...

Those little words, "put up the firewall rules as necessary" are equivalent to "and magic happens here."

It's actually not magical at all... Work with the mindset of "I want to allow X, Y, and Z, then deny everything else". This translates easily into iptables rules -j ACCEPT and then your last rule (or policy) should be a deny/drop/reject.

That is exactly what I tried to do. I just used the wrong bit of pixie dust (during some of the 'heated' IPsec meeting debates one fellow would try to sneak up a speaker 'that just did not get it' and sprinkle some glitter on them. He had labeled his tube of glitter as 'security pixie dust').

If you are interested in learning how iptables work, I suggest reading this book:

Linux Firewalls, Second Edition by Robert L. Ziegler ISBN 0-7357-1099-6

It covers everything from packet filtering concepts to practical examples.

Now here is a recommendation to follow up on. Thanks!

Christopher Chan wrote:

...

ip src/dest is used for routing decisions by the kernel. The IP state machine (check the RFC or any decent TCP/IP textbook) is really quite simple. But iptables sticks its nose into the center of that state machine and can mangle addresses to change how packets flow through the machine, or just simplely yank packets right out of the machine with a simple NO (drop).

So in my mind's eye of the IP state machine (my MSU CPS 410 prof was death on state machines; turn in a perfectly executing assignment without one and there went half your grade. See HIP for its state machine) is dictated by iptables as to what it is allowed to route.

That just means iptables can influence routing by manipulating packet headers. Routing is still controlled by the kernel.

We are playing with words here, and english tends to be too rich in interpretation. I work on standards. I let one regional joke left in an RFC: 2410, the Null ESP cipher. There we joke about the null cipher having a key length of zero. A very America joke for at the time we were killing aspects of the ITAR control on crypto export. But a few years later, over at my day job at ICSAlabs, we are trying to figure out why this one firewall product for TW is not working with the others. The connections are terminated in the ISAKMP negotiation. We dig down and find that there is an ISAKMO ESP-NULL proposal with a key payload with a value of zero. No one else is accepting this and rejects the whole ISAKMP exchange per the ISAKMP RFC. We then find a few other IPsec implementations coming out like this and all the authors are people following on, just reading the RFCs and NOT getting the joke. There are some MAD developers as they have to change their code,and some blushing IETFers as we realize we have to maintain the lore of the RFC development as there are other RFCs with zingers in them.

Over at the IEEE 802, we are voting ballots on wording that can be interpreted on way with the Webster dictionary and another with the Oxford dictionary.

So I am right about iptables controlling routing and you are right about iptables NOT controlling routing, only influencing it. What does 'control' mean in this context? IEEE is really big on state machines and truly covers the transfer of 'control' from one layer to another. Look at the MLME in 802.11. Look at the 802.1X machines. So since I have to live this control architecture and work in live debates about what layer is controling what, I have a particular language set.

BTW, should we table this debate? Webster says that means stopping, 'taking the subject off the table.' Oxford says that means to start, 'placing the subject on the table.' Boy did we have some moments back in the mid-90s with the ISO crowd descended on the IETF. Also can we reach a concensus here? Webster will accept a majority, Oxford wants complete agreement. (Or at least that is what these sources said back in the mid-90s when we lived Bernard Shaw's line of: 'Two nations separated by a common language')

:)

Now I have to hop over to the Asterisk list to figure why with one firewall the INVITE properly redirects the RTP to the RTP server, and the with the other firewall this is not in the INVITE so the RTP flow does not..... ARGH!!!!!

Christopher Chan wrote:

...

Now I have to hop over to the Asterisk list to figure why with one firewall the INVITE properly redirects the RTP to the RTP server, and the with the other firewall this is not in the INVITE so the RTP flow does not..... ARGH!!!!!

I hope you are not trying to get around a double nat situation. client -> nat <-> nat <- asterisk.

I never managed to get things to work in that scenario. I have a vpn setup to get things to work.

No. That in part of my frustration. I have 64 publicly routed addresses.

My open net is 8 addresses, for 6 systems. DSL router and so far 2 firewalls standard (occational honeypot). I assigned 8 addresses for my VoIPnet. All Trixboxes on VoIPnet have 2 NICs. Their second NIC is to an 192.168 addressed net with the various VoIP clients.

So I have a WRT54g running sveasoft with NAT turned off. But even with NAT turned off, the box is basically brain-dead. It would only allow the ONE server defined as the DMZ server to be accessed even when the firewall is disabled! And I have 2 Trixboxes (part of my testing. Have to learn DUNDI too).

So I now have a REAL firewall; well Centos wiht Shorewall. And it seemed to be working, but the SIP/SDP INVITE when I have the sveasoft box has a redirect from the SIP server to the actual RTP server. But with Shorewall, that information is NOT in the INVITE so the SIP server responds with an ICMP of no such port. And so far I have not figured this out...