>The second way to handle this is to allow the firewall to participate in
>the cyrptographic authentication and pass/drop traffic based on that. I
>can see a filtering firewall where source address is a key identifying a
>host rather than IP address. This would be nice.
>
>The problem with all of this is it only takes care of one portion of a
>firewalls' job - eliminating traffic from unwanted sources. There is a
>whole separate process of validating data to avoid data driven attacks. In
>this scenario, the firewall has to be the endpoint of the IPSec tunnel,
>much as firewalls are the endpoint of an SMTP session today. The traffic
>can be inspected and re-tunnelled to the actual recipient just as SMTP is
>repackaged and sent to the intended recipient in today's firewalls.
That's what I was picturing, two firewalls, one at the entrance to the
rest of the world and one right before your server (on a new DMZ). The
first keeps out the riff-raff, the second allows IPSec traffic from
anywhere and if that second firewall could gateway IPSec into IP, and
then do firewall things with the traffic, more power to it.
>> These are just some thoughts I have after 2 days with IPSec on
>> my host. Any comments?
>
>Yeah. What are you running IPSec on?? If you say a Windows (95!)
>workstation, you win the prize and make me wet my pants. :-)
Uh, I'll pass, but yes Win95 :-)
>Where/how/when can I get one?? We have a large user-base which are looking
>for a routed access past a firewall. I can only see IPSec (or similar VPN
>technologies) making me at all comfortable about doing this. We would
>require a filter which allows us to source a machine by key and not IP
>address. We would also require encrypted sessions to networks behind the
>firewall.
It's in the second round of beta, I don't think the beta is closed, but
I'll have to check. Drop me a note and I'll follow up.
chip
ftp software
www.ftp.com
|
|
