Re: iptables is like alchemy
On Thu, Jan 3, 2013 at 3:37 AM, Jorge Fábregas wrote: Ok, I've posted a similar setup I've used in the past that worked like a charm. The script is the actual /etc/sysconfig/iptables. You'll notice the syntax there is somehow different than when you manually create the rules (or put in a script) but you get the idea. Those rules WERE THE MINIMUM required in order to let a machine on internet reach a machine on the internal network (port 8,555). Ask me any question if you don't understand a line (please specify line number in question). eth0 is WAN, eth1 is LAN. Notice how I use -i and -o for the NICs. http://fpaste.org/sdPF/ Just to follow up on this, I had nothing but trouble from the portal server. Everything I did seemed to break unrelated stuff and none of it made any sense. It was very frustrating, and that was really why I came here to ask. Anyway, I finally gave up. To save time and what was left of my sanity, I just installed another server parallel to portal, implemented rules based on your example above, and called it a day. The new server *only* handles the masqueraded connections to the internal server. Thanks for the tips! -Alan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
Jorge Fábregas wrote:
Ok, I've posted a similar setup I've used in the past that worked like a
charm. The script is the actual /etc/sysconfig/iptables. You'll notice
the syntax there is somehow different than when you manually create the
rules (or put in a script) but you get the idea. Those rules WERE THE
MINIMUM required in order to let a machine on internet reach a machine
on the internal network (port 8,555). Ask me any question if you don't
understand a line (please specify line number in question).
eth0 is WAN, eth1 is LAN. Notice how I use -i and -o for the NICs.
http://fpaste.org/sdPF/
I run very similar to this for my firewall, other than having two ISP
connections and having to load balance outgoing sockets in a strange way (some
clients accept only from one IP or another).
At this point tcpdump is your friend. I would be suspicious that the issue is
rule 8 you posted, but without the IP of all machines I can't be sure. You don't
note if the machine with failing DNS is using internal, external or both IPs, or
at least it's not totally clear to me. Your Server2 is only on the external
net, so I presume that the IP is external.
In rule 8 you posted, I'm suspicious that something bizarre is happening, so you
might try blocking your firewall internal IP[1] or limit MASQ to connections you
initiate[2].
[1] ! -s ${my_internal_IP}
[2] -m state --state NEW
Just feels as if that is the isue, but tcpdump on the external side will tell
you what's happening if neither of those things change the problem.
HTH,
Jorge
--
Bill Davidsen david...@tmr.com
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
2013/1/3 Jorge Fábregas jorge.fabre...@gmail.com: Ok, I've posted a similar setup I've used in the past that worked like a charm. The script is the actual /etc/sysconfig/iptables. You'll notice the syntax there is somehow different than when you manually create the rules (or put in a script) but you get the idea. Those rules WERE THE MINIMUM required in order to let a machine on internet reach a machine on the internal network (port 8,555). Ask me any question if you don't understand a line (please specify line number in question). eth0 is WAN, eth1 is LAN. Notice how I use -i and -o for the NICs. http://fpaste.org/sdPF/ Hi, Could you, please, post the actual config? If the configh which you posted worked for you, then we know there's no error in it. We need to see the one which has some, you know ;). It may be something really minor, like a typo, which is very difficult to spot if you read the text for the umpteenth time, and you know what you expect to read. It may be, that all it needs is just another pair of eyes. As far as what you posted goes, if that script worked for you, then replacing the port numbers and the destination IP with the ones you need for ssh would give you ssh connectivity. However, there are no holes punched in the INPUT chain for DNS or IMAP services, I suppose that the relevant lines are present in the file which we haven't seen yet. HTH, Paweł -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
On 01/03/2013 03:47 AM, Alan Evans wrote: Anyway, the rule I posted is the only rule in use here. I have tried other iterations that did involve a MASQUERADE rule, but they didn't work either. Like I said, I've been scouring google to solve this for a long time. I see but this doesn't makes sense. That can't be the only rule in place. How are you figuring out which rules are in place? Remember you need to use: iptables -L -t nat in order to see the nat table. If you don't add the -t nat you'll only see the regular filter table. Also, if that's the only rule as you mention, where's the ALLOW rule for incoming UDP/53 traffic for DNS? Regarding MASQUERADE, as far as I know, netfilter won't do this automatically. You need to explicitly masquerade the internal network IPs or use the SNAT functionality. Please post your complete rules in pastebin or similar. There's no need to use the real IPs ports but, at least, post something that is very similar to what you have. There's no way you can do this with a simple line or two. -- Jorge -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
I'll try this tomorrow when I get into work. But at first look it seems awfully familiar, like it's something that I've already tried. Thanks, though. At this point I'll try whatever somebody thinks might work. -Alan Maybe I should have put it this way. This one does the redirect. iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 22 -j DNAT --to-destination 192.168.0.2:22 Because it goes through the forward chain you also need to allow it there as well with iptables -A FORWARD -p tcp -i ppp0 -o eth0 -d 192.168.0.2 --dport 22 -j ACCEPT You need both. Gary. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
Ok, I've posted a similar setup I've used in the past that worked like a charm. The script is the actual /etc/sysconfig/iptables. You'll notice the syntax there is somehow different than when you manually create the rules (or put in a script) but you get the idea. Those rules WERE THE MINIMUM required in order to let a machine on internet reach a machine on the internal network (port 8,555). Ask me any question if you don't understand a line (please specify line number in question). eth0 is WAN, eth1 is LAN. Notice how I use -i and -o for the NICs. http://fpaste.org/sdPF/ HTH, Jorge -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
On 01/02/2013 06:54 PM, Alan Evans wrote: This is really related to iptables, not I presume Fedora-specific. But I'm really hoping that somebody here will be able to school me on iptables, so I don't have to find and subscribe to some other list just to ask one question. For what it is worth opinion. When I had to maintain a Linux firewall, I used Shorewall for all these rule writing. Shorewall makes sense of the iptables mess. Now I run a commercial branch office class firewall for my network. Sometimes I dream of going back and rolling my own, not to put up with the vendor limitations... I'm faced with the problem of needing to punch a hole in a firewall on our portal server so that, in our case, ssh to port 20022 on external interface of that server actually just connects to port 22 on another machine located in the network on the internal interface. I hope I'm being clear. I've tried many iterations of iptables rules to accomplish this. The closest I've come is: iptables -A PREROUTING -t nat -p tcp -s 0/0 --dport 20022 -j DNAT --to 192.168.0.35:22 http://192.168.0.35:22 And indeed connecting to port 20022 on portal just goes straight to port 22 on the other (192.168.0.35) machine. The problem is, as soon as I apply this rule, DNS queries (portal is also a DNS server) to the external interface stop working. I've googled endlessly and found about a thousand variations by people that are each supposed to solve a subtly different variation on what I'm trying to do. Nothing I've tried does what I want without bad side effects like I describe above. -Alan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
iptables is like alchemy
This is really related to iptables, not I presume Fedora-specific. But I'm really hoping that somebody here will be able to school me on iptables, so I don't have to find and subscribe to some other list just to ask one question. I'm faced with the problem of needing to punch a hole in a firewall on our portal server so that, in our case, ssh to port 20022 on external interface of that server actually just connects to port 22 on another machine located in the network on the internal interface. I hope I'm being clear. I've tried many iterations of iptables rules to accomplish this. The closest I've come is: iptables -A PREROUTING -t nat -p tcp -s 0/0 --dport 20022 -j DNAT --to 192.168.0.35:22 And indeed connecting to port 20022 on portal just goes straight to port 22 on the other (192.168.0.35) machine. The problem is, as soon as I apply this rule, DNS queries (portal is also a DNS server) to the external interface stop working. I've googled endlessly and found about a thousand variations by people that are each supposed to solve a subtly different variation on what I'm trying to do. Nothing I've tried does what I want without bad side effects like I describe above. -Alan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
On Wed, 2013-01-02 at 15:54 -0800, Alan Evans wrote: This is really related to iptables, not I presume Fedora-specific. But I'm really hoping that somebody here will be able to school me on iptables, so I don't have to find and subscribe to some other list just to ask one question. I'm faced with the problem of needing to punch a hole in a firewall on our portal server so that, in our case, ssh to port 20022 on external interface of that server actually just connects to port 22 on another machine located in the network on the internal interface. I hope I'm being clear. I've tried many iterations of iptables rules to accomplish this. The closest I've come is: iptables -A PREROUTING -t nat -p tcp -s 0/0 --dport 20022 -j DNAT --to 192.168.0.35:22 And indeed connecting to port 20022 on portal just goes straight to port 22 on the other (192.168.0.35) machine. The problem is, as soon as I apply this rule, DNS queries (portal is also a DNS server) to the external interface stop working. I've googled endlessly and found about a thousand variations by people that are each supposed to solve a subtly different variation on what I'm trying to do. Nothing I've tried does what I want without bad side effects like I describe above. -Alan Hi Alan, try this ppp0=Internet connection eth0=local area network connection This will forward port 22 on the Internet to machine 192.168.0.2 port 22 on local network. iptables -A FORWARD -p tcp -i ppp0 -o eth0 -d 192.168.0.2 --dport 22 -j ACCEPT iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 22 -j DNAT --to-destination 192.168.0.2:22 Gary. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: iptables is like alchemy
On Wed, Jan 2, 2013 at 6:13 PM, Jorge Fábregas wrote: Please elaborate more. I'll try. Why does 192.168.0.35 perform DNS queries against the external interface of the firewall? Why not use the internal ip? It doesn't. I'll try to be more specific: There are at least four machines in this picture. Portal is our company's gateway between the wide internet and the local LAN. It handles a number of services and also runs bind. Machine35 is a server on the local LAN. Server2 is another server (not yet mentioned) which sits parallel to portal and is connected only to the internet. Server2 has portal as it's only nameserver, so accessing server2 by name is only possible if portal is online and running bind. Now the task I've been unhappily given is to allow ssh access to 35 directly from some other machine accessing from the internet. Call this machine Developer. The closest I've come to doing this is the rule that I posted originally. After executing that rule and no other, Developer is able to initiate a ssh connection to portal:20022 and directly log in to machine35. Beautiful. Except now, nobody can access server2 because the DNS query times out. That and the boss complains about IMAP access to portal from the outside stops working, which I figure is the same problem. Anyway, the rule I posted is the only rule in use here. I have tried other iterations that did involve a MASQUERADE rule, but they didn't work either. Like I said, I've been scouring google to solve this for a long time. So my question is sort of multi-faceted: If the rule I posted can't work without an attendant MASQUERADE rule then why did it work? I'm certain it was the only rule in effect (aside from the normal rules always effective) when I tested connectivity. Why did my rule cause other services to be blocked? I don't see anything about it that should have had that effect. Finally, what *should* I do to make this work? If you manually perform dig @192.168.0.1 google.com (I assume that's your firewall ip) from 192.168.0.35, does it work? Did you create the corresponding MASQUERADE rule (under POSTROUTING) for the egress traffic coming from 192.168.0.35? I believe so , otherwise you wouldn't have been able to connect from the outside to 20022. Please post your rules if you want more detailed help. I really don't see any relationship with what you describe DNS problems. Neither do I, and that's a big part of my problem. Thanks for being patient with my ignorance. -Alan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
