<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
How about revisting this topic Jay?<br>
<br>
<br>
On 02/15/2011 11:53 AM, Jay Nugent wrote:
<blockquote
cite="mid:Pine.LNX.4.44.1102151116030.24498-100000@home.nuge.com"
type="cite">
<pre wrap="">Greetings,
Suggestion:
- Assign the Linux box an IP on your LAN (192.168.1.88)
- Assign the Linux end of the TUN interface another IP on your LAN
(192.168.1.44)
On your gateway router to the Internet:
- Port forward SSH to the Linux address (192.168.1.88)
In this way you can remotely log onto your Linux machine to
read mail, perform maintenance, play around.
- Assign the JNOS address (192.168.1.44) as the "DMZ Host".
This lets everything *other* than SSH (which has been port
forwarded elsewhere) to be automatically directed to the JNOS
application (and into its own TCP/IP stack). In this way ALL
protocols including "IPIP Encapsulation (Protocol-4)" to go
directly to JNOS.
</pre>
</blockquote>
When we apply the above design the following happens:<br>
<ol>
<li>When we port forward ssh to the Linux host stack we find joy
in ssh.</li>
<li>When we include DMZ to the jnos stack, jnos becomes happy but
we lose ssh at the host.</li>
</ol>
It appears to us that DMZ applies absolutely to all traffic and the
port forward is lost.<br>
We find no way to force the ssh port forward to be processed prior
to the DMZ.<br>
<br>
As an alternative tactic, we don't seem to be able to selectively
forward IPIP protocol-4 to jnos stack.<br>
<br>
SO -- Is this a common issue and what alternatives permit access to
both Linux and JNOS?<br>
Replacing the gateway router is not an option.<br>
<br>
Cheers<br>
Skip<br>
</body>
</html>