On 4 Feb, Fuzzy Fox wrote:
> 118.136.195.151
> +-----+ internet +----+
> | ISP |-------------------| GW |--> to other 44.x.x.x hosts
> +-----+ +----+
> |
> | ppp0 (205.1.1.20) 44.80.42.1
> +------------+ (192.168.1.2) +--------+
> | Linux Masq |--------------------------| JNOS |---> local net
> +------------+ slip0 (192.168.1.1) +--------+ 44.80.42.0/24
>
> I like pictures. They describe things so succinctly. :)
Me too. This one looks great so I've decided to use it! I've added the
distant system I normally reach with my JNOS program and named it GW
and put on the other end of my local network. GW also links to another
JNOS in the 44.x.x.x domain.
> Anyway, your configuration here is no different from any other masq
> setup; they just normally have an eth0 interface, in place of your slip
Yes that's true in part but JNOS adds a "twist" to the situation.
> Your JNOS program doesn't know anything about how it's being masq'd,
> right?
This is also true. With IP masquerading JNOS has no idea that it's
reaching the GW machine through a masq'd machine. At least this is how I
understand masquerading to work? If JNOS does a telnet to GW, it looks
like GW is responding directly as far as JNOS knows and GW thinks it's
being called with the Linux dynamic ppp0 address?
> So how can it know to tell a remote machine to use some dynamic IP
> address instead of its own interface's IP address? This is the basic
> problem that makes applications so difficult when masq is involved.
This is where I run into my problem. JNOS *CAN* tell that remote
machine (GW) to send packets back to it. I use it every day for this
purpose. Normally, JNOS will do the dialup, establish a ppp connection
to my ISP and JNOS sends a special command to GW. This command tells GW
to route all 44.80.42.x/24 to my JNOS. GW decides what IP address to
send these packets to *solely* based on the IP address the command came
in from. When JNOS is doing the dialup the command goes out from my
dynamic assigned address within JNOS and so the packets coming from GW
use this address to send it's packets back in to JNOS. The packets
contain encapsulated IP within IP which JNOS then decodes and routes.
For example, if I ping a distant 44.x.x.x address that must go via GW,
it looks like this...
PPP: len 56 protocol: IP
IP: len 52 205.246.83.146->118.136.195.151 ihl 20 ttl 63 prot IP
IP: len 32 44.80.42.1->44.80.8.120 ihl 20 ttl 63 prot ICMP
ICMP: type Echo Request id 132 seq 0
0000 ....
PPP: len 53 (compressed ALL/UI) compressed protocol: IP
IP: len 52 118.136.195.151->205.246.83.146 ihl 20 ttl 237 prot IP
IP: len 32 44.80.8.120->44.80.42.1 ihl 20 ttl 29 prot ICMP
ICMP: type Echo Reply id 132 seq 0
0000 ....
You can see that my dynamic address is used to transport the ping
packet to GW. The second "encapsulated" IP header contains the actual
ping. My JNOS is 44.80.42.1 and I'm pinging 44.80.8.120. The response
comes back via the same path. All my packets bound for distant 44.x.x.x
hosts travel this way, "piggy-backing" on IP packets to/from GW. The
frames above where not typed by me, they were captured to a text file
when I did the ping. GW is set up to route all 44.80.42.x/24 packets to
my JNOS whenever my JNOS is sending these special command packets. In
other words, GW allows me to change it's routing table with my command
packets. These command packets are "one shot" UDP packets and require
no acknowledgment.
Now.....if I use IP masquerading as in the your drawing I seem to be
able to reach GW with my command packet and since it's masq'd, it should
appear to come from my Linux ppp0 dynamic address? GW will be sending
it's encapsulated packets back to that same dynamic address, just like
in the above two frames. I need these incoming packets to reach JNOS.
The returning packet never reaches JNOS and so it has no packet to
decode. The ping (telnet, ftp, whatever) fails.
There is a little more information I've learned fooling with it. If I
ping (telnet, ftp, etc.) a host that does NOT go via GW, it works fine.
I can also type "ipfwadm -M -l" and see the count and expire times of
the command packets JNOS is sending out to GW (the ones telling it to
route back to me) and other various packets that do not route to GW,
such as DNS lookups, etc.
If I do a ping (or anything else) that must route via GW and then do a
"ipfwadm -M -l" it reports "unexpected input data" and will not show any
other data, After a few minutes this will go away and I can once again
see the outgoing packet count, expire times, protocol (UDP) of my
outgoing command packets. In other words, it seems like every time JNOS
generates a packet that would cause GW to send one back to JNOS,
masquerading chokes on the packets coming back. I'm not sure why or what
IP address they are actually going to.
I know this is complicated but I wanted to post it anyway since I'm
stumped. I'm open to ANY ideas on why this setup works when JNOS uses
it's dynamic address directly but doesn't work when it goes via a Linux
dynamic address using masquerading. Has anyone seen this error message
reported by ipfwadm? Are there any docs besides the man page I might
read? Could it have something to do with MTU or MSS on my SLIP link?
Here is my bare bones ipfwadm test setup that I have in rc.local.
In simplest terms, I want anything FROM JNOS passed to GW to appear to
use the Linux dynamic IP address and anything FROM GW directed to the
Linux dynamic address to be passed TO JNOS.
# flush
ipfwadm -F -f
ipfwadm -I -f
ipfwadm -O -f
#
ipfwadm -I -p accept
ipfwadm -F -p deny
ipfwadm -O -p accept
# From JNOS to the world
ipfwadm -F -a m -b -S 192.168.1.0/24 -D default/0
# From the world to JNOS.
ipfwadm -F -a m -b -S default/0 -D 192.168.1.0/24
#
Thanks for your post Fuzzy. I'm still stumped but I'm not giving up!
I loose a lot of battles but I ALWAYS win the war :)
--
Scott Felton - Mount Joy, PA USA
Slackware Linux v.3.6.0
[EMAIL PROTECTED]
http://www.k3ir.ampr.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
