Cadillac84
06-01-2004, 08:03 PM
I have been having a fit over this and I finally got the answer. When I would search for answers, all I ever found was questions and half answers that didn't work.
AND, the problem was NOT with getting the router set up; the problem was knowing what to permit through the router.
OK, here is the setup. (Surely you'll know that when I use xxx.yyy.zzz in place of the last three octets of an IP that I'm just obscuring the real info. All the IPs on the private side are real.)
STATIC IP at the office on an ADSL connection.
"modem" is Westell A90 DSL modem
UTP (Cat 5) connection from Westell to eth0 in router
eth1 in router connects to private network 192.168.40.0/24
Two computers on private net desire to act as hosts using pcAnywhere 10.5 -- both are WinXP-SP1 machines. One person will connect always to one computer; another person will connect always to other computer.
Router is running 2.4.18 (SuSE 8.0) with iptables.
Home IP addresses of the two persons wishing entrance are known and "stable" dynamic. (That means that they do NOT have static IPs but that their IPs almost never change.) One is using a Netgear MR814v2 which seems to hold on to its IP over time. The other is using a Linux router identical to the one at the office, and every time it is rebooted, it "requests" the same IP it last had and seems always to get it.
Therefore, it is possible to put only a few permissible sources into the list of approved callers and get away with it.
So, here is what I did.
We'll call the one person Charlie and the other person Joe.
#!/bin/bash
# bunches of other stuff
Steve = "mmm.nnn.ooo.ppp" # routable public static IP
Steve_ = "192.168.1.97" # this is what eth0 gets from
# the Westell NAT and it works
# so I don't mess with it.
Charlie1 = "24.xxx.yyy.zzz"
Joe1 = "64.aaa.bbb.ccc"
# representing IPs almost certain to be where the calls originate
# if the IP changes, we can make a secure connection to the
# office and change Joe1 or Charlie1 or add a Joe2 or whatever
#
# Whenever Charlie calls into the external interface
# from his normal IP, forward his request -- ACCEPT
iptables -A FORWARD -i $EXTINT -s $Charlie1 -j ACCEPT
# If Charlie coming from his normal IP is requesting a
# connection to Steve that appears to be a request
# for a connection to Steve_ (the private IP of Steve)
# and it is destined for port 5631 (tcp) or 5632 (udp)
# we will pass it to Charlie's preferred workstation
# whose address is 192.168.40.25 on the private net.
iptables -t nat -A PREROUTING -p tcp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 5631 \
-j DNAT --to-destination 192.168.40.25:5631
iptables -t nat -A PREROUTING -p udp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 5632 \
-j DNAT --to-destination 192.168.40.25:5632
# Likewise, we'll include the two POSTROUTING rules
# to cover backtalk from Charlie's workstation to him
# I'm not sure these are really needed; I'll experiment
# with it tonight and let you know.
iptables -t nat -A POSTROUTING -p tcp \
-s 192.168.40.25 --dport 5631 -j SNAT --to $Charlie1
iptables -t nat -A POSTROUTING -p udp \
-s 192.168.40.25 --dport 5632 -j SNAT --to $Charlie1
# That takes care of Charlie; now for Joe. Note that Joe
# gets the same treatment except if the request is coming
# from Joe's normal IP, it will be routed to Joe's preferred
# workstation which is 192.168.40.13
iptables -A FORWARD -i $EXTINT -s $Joe1 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -i $EXTINT \
-s $Joe1 -d $Steve_ --dport 5631 \
-j DNAT --to-destination 192.168.40.13:5631
iptables -t nat -A PREROUTING -p udp -i $EXTINT \
-s $Joe1 -d $Steve_ --dport 5632 \
-j DNAT --to-destination 192.168.40.13:5632
iptables -t nat -A POSTROUTING -p tcp \
-s 192.168.40.13 --dport 5631 -j SNAT --to $Joe1
iptables -t nat -A POSTROUTING -p udp \
-s 192.168.40.13 --dport 5632 -j SNAT --to $Joe1
# Now, here's how we found out that the calls to
# Steve were appearing to be calls to Steve_
# Turn on LOGGING!
#------------------------------------------------------------------
# LOGGING ENABLED 5/31/04
# For troubleshooting maintenance activities.
#
# Uncomment for debugging or logging
# Log is in /var/log/messages
#------------------------------------------------------------------
iptables -A INPUT -j LOG --log-prefix "INPUT_DROP: "
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT_DROP: "
#-----------------------------------------------------------
# End of this section of iptables script
The LOGGING was how I finally determined how to solve the problem. Charlie leaves pcAnywhere in host mode waiting for call and goes home. He make his CONNECT to the ROUTABLE STATIC IP == Steve by putting Steve's IP mmm.nnn.ooo.ppp into his pcAnywhere remote at home. Connect to host mmm.nnn.ooo.ppp
But, the connection didn't go through. Looking at the log, (/var/log/firewall) revealed that connections had been DROPPED from 192.168.1.97 and that really surprised me.
Here is a line from the log.
May 31 10:25:05 Steve kernel: INPUT_DROP: IN=eth0 OUT= MAC=00:20:af:17:4f:43:00:60:0f:22:31:c3:08:00 SRC=24.xxx.yyy.zzz DST=192.168.1.97 LEN=48 TOS=0x00 PREC=0x00 TTL=41 ID=12068 DF PROTO=TCP SPT=1367 DPT=5631 WINDOW=65535 RES=0x00 SYN URGP=0
Everything looks fine except the DST. I had asked to be connected to mmm.nnn.ooo.ppp:5631 but the packet that was dropped for not meeting the rules was destined for 192.168.1.97:5631.
Well, durn my hide, I said to myself. So, I made an secure connect to the router and put Steve_ = 192.168.1.97 and changed the -t nat PREROUTING lines to $Steve_ and ran the script again and I was in like Flynn.
Now, you should enable logging if you try this. I should have done that long ago and I would have seen the problem and kept some of my (formerly) brown hair!!! :mad:
If you get in, fine! If you don't, look at the log. I recognized the 192.168.1.97 because when I do an ifconfig eth0, that's what it shows me.
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:20:AF:17:4F:43
inet addr:192.168.1.97 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: xxxx::xxx:xxxx:xxxx:xxxx/xx Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
and so on.
So, how could Charlie connect to Joe's computer?
Just by adding a few more lines of script. And changing the port that Charlie requests. In the Remote section of his home computer's pcAnywhere, he adds a remote which he might call Joe's Computer. He checks TCP/IP and clicks on Details. Then he changes his Data port to 9631 and his Status port to 9632. When "Steve" sees the request for a destination port of 9631 (tcp) and 9632 (udp), he will route that to 192.168.40.13:5631 so the office computers can just be waiting and Charlie can take his pick and Joe can do as he's told. (I'm Charlie and Joe doesn't know how to do this stuff!) :D
iptables -t nat -A PREROUTING -p tcp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 9631 \
-j DNAT --to-destination 192.168.40.13:5631
iptables -t nat -A PREROUTING -p udp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 9632 \
-j DNAT --to-destination 192.168.40.13:5632
Questions?
I will check back on this to tell you what happens about the POSTROUTING. Somebody put that into the message on what he was using and I tried it. Since I got in OK, it didn't occur to me to delete the POSTROUTING and see if that made it stop working. But I'll do that tonight and report back.
Added after another test of system:
------------------------
As those of you who know more about all this than I probably already had known, POSTROUTING doesn't have anything to do with it. I commented the two POSTROUTING lines out and restarted the filter script and got right back in.
So, it takes only three lines to make it work -- that, plus knowing what IP to put in for the source.
If you wanted to leave it open for anybody to get to it, you could just do it with one line. Matter of fact, I guess you could just not have a firewall at all! But, I choose to be very careful and I open the services up only to specific people. I may not be invisible, but nmap rates me very difficult and "(good luck)"
With that, I leave you.
:D
AND, the problem was NOT with getting the router set up; the problem was knowing what to permit through the router.
OK, here is the setup. (Surely you'll know that when I use xxx.yyy.zzz in place of the last three octets of an IP that I'm just obscuring the real info. All the IPs on the private side are real.)
STATIC IP at the office on an ADSL connection.
"modem" is Westell A90 DSL modem
UTP (Cat 5) connection from Westell to eth0 in router
eth1 in router connects to private network 192.168.40.0/24
Two computers on private net desire to act as hosts using pcAnywhere 10.5 -- both are WinXP-SP1 machines. One person will connect always to one computer; another person will connect always to other computer.
Router is running 2.4.18 (SuSE 8.0) with iptables.
Home IP addresses of the two persons wishing entrance are known and "stable" dynamic. (That means that they do NOT have static IPs but that their IPs almost never change.) One is using a Netgear MR814v2 which seems to hold on to its IP over time. The other is using a Linux router identical to the one at the office, and every time it is rebooted, it "requests" the same IP it last had and seems always to get it.
Therefore, it is possible to put only a few permissible sources into the list of approved callers and get away with it.
So, here is what I did.
We'll call the one person Charlie and the other person Joe.
#!/bin/bash
# bunches of other stuff
Steve = "mmm.nnn.ooo.ppp" # routable public static IP
Steve_ = "192.168.1.97" # this is what eth0 gets from
# the Westell NAT and it works
# so I don't mess with it.
Charlie1 = "24.xxx.yyy.zzz"
Joe1 = "64.aaa.bbb.ccc"
# representing IPs almost certain to be where the calls originate
# if the IP changes, we can make a secure connection to the
# office and change Joe1 or Charlie1 or add a Joe2 or whatever
#
# Whenever Charlie calls into the external interface
# from his normal IP, forward his request -- ACCEPT
iptables -A FORWARD -i $EXTINT -s $Charlie1 -j ACCEPT
# If Charlie coming from his normal IP is requesting a
# connection to Steve that appears to be a request
# for a connection to Steve_ (the private IP of Steve)
# and it is destined for port 5631 (tcp) or 5632 (udp)
# we will pass it to Charlie's preferred workstation
# whose address is 192.168.40.25 on the private net.
iptables -t nat -A PREROUTING -p tcp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 5631 \
-j DNAT --to-destination 192.168.40.25:5631
iptables -t nat -A PREROUTING -p udp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 5632 \
-j DNAT --to-destination 192.168.40.25:5632
# Likewise, we'll include the two POSTROUTING rules
# to cover backtalk from Charlie's workstation to him
# I'm not sure these are really needed; I'll experiment
# with it tonight and let you know.
iptables -t nat -A POSTROUTING -p tcp \
-s 192.168.40.25 --dport 5631 -j SNAT --to $Charlie1
iptables -t nat -A POSTROUTING -p udp \
-s 192.168.40.25 --dport 5632 -j SNAT --to $Charlie1
# That takes care of Charlie; now for Joe. Note that Joe
# gets the same treatment except if the request is coming
# from Joe's normal IP, it will be routed to Joe's preferred
# workstation which is 192.168.40.13
iptables -A FORWARD -i $EXTINT -s $Joe1 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -i $EXTINT \
-s $Joe1 -d $Steve_ --dport 5631 \
-j DNAT --to-destination 192.168.40.13:5631
iptables -t nat -A PREROUTING -p udp -i $EXTINT \
-s $Joe1 -d $Steve_ --dport 5632 \
-j DNAT --to-destination 192.168.40.13:5632
iptables -t nat -A POSTROUTING -p tcp \
-s 192.168.40.13 --dport 5631 -j SNAT --to $Joe1
iptables -t nat -A POSTROUTING -p udp \
-s 192.168.40.13 --dport 5632 -j SNAT --to $Joe1
# Now, here's how we found out that the calls to
# Steve were appearing to be calls to Steve_
# Turn on LOGGING!
#------------------------------------------------------------------
# LOGGING ENABLED 5/31/04
# For troubleshooting maintenance activities.
#
# Uncomment for debugging or logging
# Log is in /var/log/messages
#------------------------------------------------------------------
iptables -A INPUT -j LOG --log-prefix "INPUT_DROP: "
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT_DROP: "
#-----------------------------------------------------------
# End of this section of iptables script
The LOGGING was how I finally determined how to solve the problem. Charlie leaves pcAnywhere in host mode waiting for call and goes home. He make his CONNECT to the ROUTABLE STATIC IP == Steve by putting Steve's IP mmm.nnn.ooo.ppp into his pcAnywhere remote at home. Connect to host mmm.nnn.ooo.ppp
But, the connection didn't go through. Looking at the log, (/var/log/firewall) revealed that connections had been DROPPED from 192.168.1.97 and that really surprised me.
Here is a line from the log.
May 31 10:25:05 Steve kernel: INPUT_DROP: IN=eth0 OUT= MAC=00:20:af:17:4f:43:00:60:0f:22:31:c3:08:00 SRC=24.xxx.yyy.zzz DST=192.168.1.97 LEN=48 TOS=0x00 PREC=0x00 TTL=41 ID=12068 DF PROTO=TCP SPT=1367 DPT=5631 WINDOW=65535 RES=0x00 SYN URGP=0
Everything looks fine except the DST. I had asked to be connected to mmm.nnn.ooo.ppp:5631 but the packet that was dropped for not meeting the rules was destined for 192.168.1.97:5631.
Well, durn my hide, I said to myself. So, I made an secure connect to the router and put Steve_ = 192.168.1.97 and changed the -t nat PREROUTING lines to $Steve_ and ran the script again and I was in like Flynn.
Now, you should enable logging if you try this. I should have done that long ago and I would have seen the problem and kept some of my (formerly) brown hair!!! :mad:
If you get in, fine! If you don't, look at the log. I recognized the 192.168.1.97 because when I do an ifconfig eth0, that's what it shows me.
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:20:AF:17:4F:43
inet addr:192.168.1.97 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: xxxx::xxx:xxxx:xxxx:xxxx/xx Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
and so on.
So, how could Charlie connect to Joe's computer?
Just by adding a few more lines of script. And changing the port that Charlie requests. In the Remote section of his home computer's pcAnywhere, he adds a remote which he might call Joe's Computer. He checks TCP/IP and clicks on Details. Then he changes his Data port to 9631 and his Status port to 9632. When "Steve" sees the request for a destination port of 9631 (tcp) and 9632 (udp), he will route that to 192.168.40.13:5631 so the office computers can just be waiting and Charlie can take his pick and Joe can do as he's told. (I'm Charlie and Joe doesn't know how to do this stuff!) :D
iptables -t nat -A PREROUTING -p tcp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 9631 \
-j DNAT --to-destination 192.168.40.13:5631
iptables -t nat -A PREROUTING -p udp -i $EXTINT \
-s $Charlie1 -d $Steve_ --dport 9632 \
-j DNAT --to-destination 192.168.40.13:5632
Questions?
I will check back on this to tell you what happens about the POSTROUTING. Somebody put that into the message on what he was using and I tried it. Since I got in OK, it didn't occur to me to delete the POSTROUTING and see if that made it stop working. But I'll do that tonight and report back.
Added after another test of system:
------------------------
As those of you who know more about all this than I probably already had known, POSTROUTING doesn't have anything to do with it. I commented the two POSTROUTING lines out and restarted the filter script and got right back in.
So, it takes only three lines to make it work -- that, plus knowing what IP to put in for the source.
If you wanted to leave it open for anybody to get to it, you could just do it with one line. Matter of fact, I guess you could just not have a firewall at all! But, I choose to be very careful and I open the services up only to specific people. I may not be invisible, but nmap rates me very difficult and "(good luck)"
With that, I leave you.
:D