On 11/13/06, Dan McDonald <[EMAIL PROTECTED]> wrote:
On Mon, Nov 13, 2006 at 10:24:15PM -0500, Eric Enright wrote:
> On 11/13/06, Dan McDonald <[EMAIL PROTECTED]> wrote:
> >NOTE;  It's spelled IPsec with a small 's'.  :)
>
> ;)

Honestly, it's a big pet peeve among Team IPsec.  Bill even filed a bug:

        6483187 It's capitalized "IPsec", damnit!

"IPsec" is the technology and protocol suites.  "IPSEC_" can be used in .h
files, and "ipsec_" in .c and in filename, but that's about it!

Enough yapping, let's get to the good stuff...

> >> # ifconfig mxfe0
<SNIP!>
> >Interesting.  You had ROUTER enabled, according to your ifconfig.
>
> Initially I did "ifconfig ip.tun0 router up" as per the docs at:
>
> http://docs.sun.com/app/docs/doc/816-4554/6maoq0223?a=view
>
> However, ROUTER seems to be enabled by default:
>
> # ifconfig ip.tun0 unplumb
> # ifconfig ip.tun0 plumb
> # ifconfig ip.tun0
> ip.tun0: flags=11008d0<POINTOPOINT,RUNNING,NOARP,MULTICAST,ROUTER,IPv4>
> mtu 65515 index 6
>        inet tunnel src 0.0.0.0
>        tunnel hop limit 60
>        inet 0.0.0.0 --> 0.0.0.0 netmask 0
>
> Possibly because I have ip_fowarding enabled?
>
> # routeadm
>              Configuration   Current              Current
>                     Option   Configuration        System State
> ---------------------------------------------------------------
>            IPv4 forwarding   enabled              enabled
>               IPv4 routing   default (enabled)    enabled

Yep.  That'll do it.

Our IPsec remote-access gateway we run in Solaris development ("punchin") has
ipv4-forwarding *DISABLED* by default and we turn it on per-interface
explicitly.  Then again, we don't run NAT on the punchin server.  And we
don't forward traffic to the Internet.

So this would be a host with a public address, that only sends traffic
out ip.tun0 and it's internal interface?

I hope my newness to IPsec is showing here.

> >If mxfe0 (physical) and ip.tun0 are the only interfaces for your machine,
> >then you don't need to worry about IP forwarding at all.
>
> They are not.  I have hme0 configured to serve my internal network,
> connected to a switch:
>
> # ifconfig hme0
> hme0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index
> 2
>        inet 192.168.0.1 netmask ffffff00 broadcast 192.168.0.255
>        ether 8:0:20:a4:f2:40
>
> My intent is to use hme0:1 on 192.168.44.x/24 until I can reconfigure
> my home network to use a different subnet altogether, as
> 192.168.0.x/24 is already being used by an office on the VPN.

So in my diagram below, I swap "mxfe1" for "hme0" and I get the idea.  Cool.

This means all of your interfaces are forwarding, and you can leak packets
from the Internet into your internal network.  This is Not Secure (TM), and
you may be compromising your internal network right now!!!

This is something I certainly do not want, *especially* if I do get
this tunnel running the way I was hoping to.

Then again, you're using ipfilter somewhere, so you may be mitigating these
circumstances *somewhat*.

Yes, mxfe0 is defaulted to block-all, and the only holes at the moment
is ssh and http.  Having the possibility there though does not sit
well with me.

> >Is this ASCII picture what you had in mind?
> >
> >
> >        +-----+------------+------------------+   192.168.44.0/24
> >              |            |
> >          <some-node>      |
> >                           |
> >                         mxfe1   192.168.44.x/24
> >                     +-----+---+
> >                     | VPN-GW  |
> >                     +----+----+
> >                        mxfe0    11.11.11.11/24
> >                          |
> >                         |ip.tun0|
> >                         |       |
> >        +---<Internet>----+-----------------------+
>
> Pretty much.  I want all traffic to 10.10.10.x/24 going through
> ip.tun0, but all other traffic (i.e, bound for the general internet)
> only through mxfe0 and NOT ip.tun0.

Oooof, you can get away with this with a proper ipfilter configuration, as
you hint at later.  It's very dangerous to have one node acting as both VPN
gateway and general router or NAT-box for your internal network.

Okay, this answers at least one of my questions -- this is not a
typical setup.  One idea I was thinking about was forwarding IPsec
traffic, which I believe is ESP and AH protocols, from the internet
into a separate box in the internal network and let that do routing
for me.  Would that be feasible?

> >If I'm right, and you're running a real GW where a piece of your internal
> >network is now in your house, you need:
> >
> >        ROUTER set on mxfe1 and ip.tun0
> >
> >        ROUTER cleared on mxfe0
> >
> >for the best security.
>
> Removing ROUTER from mxfe0 breaks the home network.

Ahhh, but given you want to route to both an Internal network AND an external
network, I see where you're going.  That makes sense.

Once IP Instances integrates, it might be possible to reconfigure things to
have one zone's IP Instance act like I describe (no internet forwarding), and
another zone's IP Instance act like you had it prior to trying to tunnel
(general router or NAT-box).

Right.  I read that currently zones can not do IPsec/routing.
Interesting that this ability may be in the future.

> I don't have a problem using ipf to forward appropriate traffic to a
> specific machine in the local network.  (Note: my current ipf setup is
> allowing all traffic from 22.22.22.22 to get in).

I despise NAT, so I don't have much knowledge on how to configure it.  (NAT
is ugly, but necessary - I do understand that.  I still despise it, though.
See my early blog entries for why.)

Yes, so do I.  I wait for the day when ipv6 is common among ISPs...

So lemme make sure I understand your desired situation:

        mxfe0 ---> Outside interface, probably has a default-route to the
                   Internet, or at least another NAT box.

Yes.  Directly connected to the internet, with zero restrictions.

        hme0 ---> Inside interface.  You currently have two prefixes on it,
                  one for your company's internal network, and one for your
                  home network.  You intend to collapse these into one prefix
                  that's unique within your firm's IP topology.

Correct.

        ip.tun0 ---> You intend to have traffic for traffic to/from your
                     firm's internal network.

Correct.

        Your node may be NAT-ting all hme0 addresses that go to the
        Internet, but not NAT-ting the ones bound for your firm (assuming you
        get that unique-to-your-firm prefix).  Either that, or you have
        another NAT box that does it between mxfe0 and the Internet.

I have to say that if a Sun employee had wired up something like this, IT
would have grounds to get him/her fired.  It's a BIG security risk.

So you have made abundantly clear ;)

If I decide to keep this as something permanent I could probably get
another ip address from my ISP to use, and do it properly.  That being
said, I'm now more curious than anything if/how it could be done with
my original idea.

Having said that, you need to make sure you have your routing story straight:

        - Your company's internal networking topology needs to be injected
          into your node's routing tables for forwarding over ip.tun0.
          in.routed can do this, but I'm not sure if it can do that AND be an
          ICMP Router Discovery agent for the rest of your traffic on mxfe0.
          Manual configuration is probably the best thing to do here.

        - If you're doing IPfilter stuff, you need to either use static
          configuration for those routes (and match what's appropriate in
          your IPfilter configuration) or somehow manage to keep ipfilter up
          to date via "route monitor" or something even more egregious.

        - Most importantly, WITHOUT some sort of IPfilter magic, a grinning
          weirdo can inject packets from the outside that are intended for
          your firm's internal network, and your node will happily forward
          them none the wiser.  This is why IT security types cringe at such
          "split tunnels".

What you're proposing can be done, but it will have to be done CAREFULLY.
I'm fascinated by the concept, and we should probably take this off-list to
work out details (with real IP numbers, yadda yadda) and summarize back to
the list when we reach a conclusion.

I'm quite interested in trying the above, maybe even putting on a
grinning weirdo hat for a weekend.

Reply to me off-list and we'll see what can be done.

--
Eric Enright
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to