Sharing internet connection breaks port forwarding

acmeinc · 03-20-2009, 02:01 PM

Not sure if this is a Linux problem, or an issue with my router. I recently discovered, and implemented, how to share my internect connection from wlan0 to eth0, using firestarter. Since sharing this connection, my port forwarding for SSH/FTP/HTTP/ect no longer works. Now, when I close the eth0 connection, the shared connection, the bridge if you willl; forwarding works as normal. Port forwarding seems to break only when the internet connection sharing is active. Any ideas?

blackhole54 · 03-21-2009, 06:48 AM

You speak of a bridge. Are you bridging wlan0 and eth0 together? If so, have you actually brought the bridge interface up? (If so, I think it should it appear when you run the ifconfig command. Disclaimer: while I have read about bridges I have not actually set one up.) And does the bridge interface have the IP address you are port forwarding to? And does your firewall allow the new connection attemps from the bridge interface?

I have shared an Internet connection from dialup with a LAN, but that did not involve bridging. A similar setup should work in your case. (You may also be able to do it with bridging; this is just a different way.) In this case wlan0 and eth0 would have different IP addresses (actually, they would be on different subnets) and you would enable IP forwarding to share the connection. In this case, if you wanted DHCP on your LAN (eth0) you would have to set up your own DHCP server on the forwarding machine.

If I have totally misunderstood your talk about a bridge, please clue me in.

(Another disclaimer: I have not used Firestarter, but I am familiar with the underlying iptables/netfilter.)

acmeinc · 03-21-2009, 11:39 PM

All of those outputs that are necessary and my method is posted on link below:

http://www.linuxquestions.org/questi...router-711911/

jeff_k · 03-22-2009, 03:10 PM

I haven't taken the time yet to go through your whole complicated setup, but I wonder - are you trying to forward port 22 and also assume that it is available unforwarded at the same time to serve ssh on a given interface?

In your ssh server config file, you can specify multiple ports for sshd to simultaneously listen on. I would recommend that you forward one of the ports and not forward another, and then try an ssh connection to each respective port to debug your problem.

blackhole54 · 03-23-2009, 06:13 AM

The port forwarding you are trying to do ... Is the destination machine the one you are running Firestarter on or the other machines on the (wired) LAN?

If the forwarded ports are for the machine running Firestarter, I don't see any provisions in the firewall to accept any new connections. I.e. the INBOUND chain will accept RELATED and ESTABLISHED udp and tcp packets, but if a packet arrives that tries to initiate a new connection I think it gets blocked. As I read the LSI chain you should see these blocked packets listed in /var/log/syslog (for Ubuntu). Firestarter should have some provision for enabling selected services.

EDIT: All of the logging rules are rate limited, so if there is a flurry of blocked packets some of them may not get logged. I doubt this would interfere with locating the dropped, port-forwarded packets in syslog.

acmeinc · 03-23-2009, 10:00 AM

Simply put.

I have a Linksys router, from which I forward ports 20-25 to my wireless machine, 192.168.10.100.
Before enabling "Internet Connection Sharing" via 'firestarter', I am able to SSH/ping/telnet into my machine.
After enabling Connection Sharing this still works until I actually share the connection by clicking Auto Eth0 to connect my Network Connections.

blackhole54 · 03-24-2009, 12:52 AM

Have you checked /var/log/syslog for blocked packets? Here is what such an entry looks like on my machine for a blocked (and logged) telnet attempt (I've added line breaks for readability):

Code:

Mar 23 23:36:39 ratel kernel: [17191994.920000]  IN=eth0 OUT=
MAC=00:18:f3:xx:xx:xx:00:50:da:xx:xx:xx:08:00 SRC=192.168.x.5
DST=192.168.x.27 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5821 DF
PROTO=TCP SPT=52698 DPT=23 WINDOW=16060 RES=0x00 SYN URGP=0

So you might try:

Code:

grep " DPT=2[0-5] " /var/log/syslog

to look for such entries.

Also see if the following turns up any matches:

Code:

grep -i martian /var/log/syslog

acmeinc · 03-24-2009, 01:13 AM

I should have gotten around to this earlier. And I apologize to everyone whom has looked into this. You were right, frickin Firestarter blocks access by default, wtf?!? So I told firestarter to allow access from ports 21-22 and everything is now working fine.

By the way, thanks for the helpful commands above. I like the first 'grep' command to check for blocked packets!

jeff_k · 03-24-2009, 10:34 PM

Firestarter will, by default, be permissive by default or prohibitive by default -- your choice -- this is set up in the preferences menu, for both inbound and outbound connections.

By the way, as I mentioned, if you want to have ssh both forwarded and not forwarded simultaneously, in the config file (for Debian, it is located at /etc/ssh/sshd_config ),
instead of just having one line containing:
Port 22
add another line to simultaneously set up sshd on another port, for example, for 22222:
Port 22222
Now just forward port 22 on to another machine. For ssh into the router machine, you use port 22222. You need to restart ssh for this to work. As far as I can tell, you can have as many instances of sshd listening as you want.

blackhole54 · 03-25-2009, 12:04 AM

Quote:

Originally Posted by acmeinc

... frickin Firestarter blocks access by default, wtf?!?

I am not familiar with Firestarter in particular, but TMK this is fairly standard behavior for firewalls. (Although I did note jeff_k's comment about Firestarter's options.) Generally firewalls will block all incoming traffic by default and allow only what has been enumerated. In computer security it is considered a losers's game to try to anticipate everything a "bad guy" might try and just block those.

(Of course, if you write your own iptables' script you can mix and match DROP and ACCEPT -- but you need to be careful. I've done this, but, even then, the overall "tone" of the firewall has been to block by default on the inbound traffic.)

acmeinc · 03-25-2009, 11:04 PM

Actually I wish I knew what firestarted did so I could write my own IPtables. I'd rather set this up via command line rather than click "share connection" in the firestarter GUI. Perhaps you could help with that.

blackhole54 · 03-26-2009, 12:53 AM

Quote:

Originally Posted by acmeinc

Actually I wish I knew what firestarted did so I could write my own IPtables. I'd rather set this up via command line rather than click "share connection" in the firestarter GUI. Perhaps you could help with that.

I went back and looked at the previous thread again where you were getting a start at this. I don't have time right now to really digest that thread and see what went right and what went wrong. But I can make some quick comments now that might get you on your way. I'll try to get time to revisit this within the next few days.

Firestarter is basically taking the second aproach maxut listed in post #2 of the other thread. Firestarter is using MASQUERADE instead of SNAT (in the POSTROUTING chain). They do similar things, but MASQUERADE is intended for transient connections while SNAT is generally recommended for long term connections that are not going to be changing IP address. So in your case I would think SNAT would be better. But as you have seen, MASQUERADE will work.

I believe the other thread covers enabling IPv4 forwarding adequately. I *think* it also covers IP addresses for your two NICs, but I didn't look at that discussion in detail.

Beyond those, Firestarter is (possibly) doing two other things for you.: 1) Providing a firewall, which you may decide you don't want or may wish different rules, and (maybe) 2) configuring/starting a DHCP server (ndhcp3-server).

The DHCP server is needed if the client machines on your LAN (hub connected to eth0) are set up for DHCP. If you configure those clients manually (which can rapidly become a real pain if you have many or change them often) then you do not need to set up a DHCP server. The DHCP server is designed to be very flexible (and powerful) which can make figuring out its configuration file a bit confusing. But Firestarter has presumably already set one up for you. You might want to take a look at it. On my older Red Hat systems the file is /etc/dhcpd.conf, but it might be slightly different on Ubuntu. If you can't find it, try:

Code:

locate  dhcp | grep  conf | fgrep /etc

Hopefully this will give you some things to think about. If you have questions, post them. I will try to get back to this shortly.

EDIT: (In my first pass, I mangled the SNAT/MASQUERADE discussion, including which chain they are in! I have simply corrected the mess w/o trying to indicate what was originally posted.)

blackhole54 · 03-29-2009, 02:18 AM

OK. I've now had a chance to read through the first thread in detail. Everything I said in my previous post still applies. What's missing from that post is configuring your network interfaces and a script for your iptables' rules.

As maxut mentioned, /etc/network/interfaces controls your network interfaces. Any interface not in that file will be handled by NetworkManager. Anything that is in that file will not be handled by NetworkManager. The default interfaces file you listed in post #7 (other thread) leaves everything except loopback to be handled by NetworkManager.

I have never used /etc/network/interfaces to configure a wifi connection, so you are are going to have to figure that out on your own -- unless somebody else posts with that info. (If you do figure it out on your own, it would be nice for you to post it to help anybody else who finds this thread.) I have set up interfaces files for controlling ethernet ports. For your setup, a file to automatically bring up eth0 with a static address might look like:

Code:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.0.1
        netmask 255.255.255.0
        broadcast 192.168.0.255

Add the lines for wan0 after you figure out how to do that. Again, the man page for this is called interfaces.

(Before altering any configuration file -- such as /etc/network/interfaces -- be sure to backup the original file so you can always go back in case something doesn't work out.)

Before you delve into writing firewall scripts, you should familiarize yourself with iptables. The generic reference for iptables, of course, is its man page. You also might want to look up the packet-filtering-HOWTO for discussion of using iptables as a firewall and the NAT-HOWTO for network translation (NAT).

But just to give you a little flavor, here is an example of a very basic firewall script you can use. For illustration, I have it accepting incoming SSH connections. You can add similar rules for any other services you wish to run. (Warning: I have not tested this. But the concepts should be right.)

Code:

#!/bin/sh

#  Basic Firewall script which,
#     Enables IPv4 forwarding so this machine can be used as a router
#     Allows all outgoing connections.
#     Allows incoming SSH from WAN
#     Allows incoming packets which have a state of ESTABLISHED or RELATED
#     Block all other incoming packets from WAN
#     Allows computers on the LAN to establish Internet connections but blocks
#        any connections from WAN to other computers on the LAN
#
#  This script provides basic firewall functionality but does not attemp
#  to block restricted addressses, weird flag configurations, etc.

#  Some definitions

IPT=/sbin/iptables
WAN=wan0
LAN=eth0
WAN_IP=192.168.10.100
LAN_SUBNET=192.168.0.0/24

#  Flush chains and set policy:

$IPT -F
$IPT -t nat -F
$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT

#  -------------------------------------------------------------------
#  INPUT chain:

#  It is *really* a good idea to allow loopback packets!

$IPT -A INPUT -i lo -j ACCEPT

#  Allow ESTABLISHED/RELATED packets

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow $WAN packets to establish connection to SSH server
#  (Likewise add other services as desired.  $WAN restriction can be
#   dropped if desired.)

$IPT -A INPUT -i $WAN -p tcp --dport 22 -m state --state NEW -j ACCEPT

#  LOG packets we are going to drop, but impose a reasonable rate limit

$IPT -A INPUT -m limit --limit 20/minute --limit-burst 10 -j LOG \
   --log-prefix " {INPUT chain} "

#  -------------------------------------------------------------------
#  FORWARD chain:

#  FORWARD all valid packets from LAN to WAN.
#  Don't allow any connections to be established from WAN
#  (If you want to restrict where LAN users can go on the Internet,
#   or what ports they can access, this is the place!)

$IPT -A FORWARD -m state --state  ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -i $LAN -o $WAN -m state --state NEW -j ACCEPT
$IPT -A FORWARD -m limit --limit 20/minute --limit-burst 10 -j LOG \
   --log-prefix " {FORWARD chain} "

#  -------------------------------------------------------------------
#  No OUTPUT rules since we are being totally permissive about that

#  -------------------------------------------------------------------
#  POSTROUTING chain

#  SNAT packets going from $LAN to $WAN so that they look like they originate
#  from this machine.  This keeps the upstream router from needing to know
#  how to route return packets.

$IPT -t nat -A POSTROUTING -o $WAN -s $LAN_SUBNET -j SNAT --to-source $WAN_IP

#  -------------------------------------------------------------------
#  End of Firewall Rules.
#  Now we just need to enable IPv4 forwarding to allow this machine to
#  function as a router. (I.e. allow LAN to get to WAN.)
#  (Alternatively this can be done in /etc/sysctl.conf)

echo "1" > /proc/sys/net/ipv4/ip_forward

You will need to arrange for a script like this to run at startup. You will probably also want to allow DHCP run at startup but not allow Firestarter to run. I am assuming you know how to do this. If not, ask.