[THIN] Fwd: Re: WHY

So what you want to do is to bring the traffic onto the internal network and
then route it outside using another firewall?


2008/4/30 Chad Schneider (IT) <Chad.M.Schneider@xxxxxxxxxxxxx>:

>  EXACTLY what we are looking at!
>
> Chad Schneider
> Systems Engineer
> ThedaCare IT
> 920-735-7615
>
> >>> On 4/30/2008 at 9:58 AM, <andrew.wood@xxxxxxxxxxxxxxxx> wrote:
>
> Ah, now I can ...  say you give your user a corporate laptop for working
> from home – you want to allow them to browse the internet, like they do in
> the office. What you **don't** want to do is allow that browsing to
> adversely impact on your end device and make that that device a gateway into
> your network – so **all** outbound traffic from the remote device comes
> through the VPN, onto the internal network and then out again through the
> corporate proxy and whatever rules and monitoring you have in place.
>
>
>
> I realise thats not as efficient as (say) allowing the user to browse
> directly from their own internet connection – but it from an audit/security
> point of view that configuration is easier to manage.
>
>
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Berny Stapleton
> *Sent:* 30 April 2008 15:44
>
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: WHY
>
>
>
> So why not put some other IP address space, such as if you are using 10.x
> for your internal use some 192.168 or vice versa on the connections for the
> CAG SSL VPN / IPSEC VPN connections and treat think of them as another
> interface, as opposed to being part of the internal network. My thought
> would be is that unless the traffic is coming down the TX pair from the
> switch that connects to the internal interface of your firewall, and it's
> addressed in those subnets, it's not internal traffic.
>
> RE: any filters/caching/auditing/scanning that you've got set up."
>
> Unless this is a limitation of the CAG why not just setup the scanning to
> do exactly this, but from the address space of the VPN / IP SEC sessions
> instead of the internal network?
>
> I can't see the logic in bringing the traffic through the external
> interface decrypting it, forcing it in across the internal interface (As
> that's not where the routing table is going to send it by default) to get
> your scanning and then routing it again onto the external interface.
>
> Berny
>
> 2008/4/30 Chad Schneider (IT) <Chad.M.Schneider@xxxxxxxxxxxxx>:
>
> "Otherwise, someone connecting on the external interface is being routed
> straight out onto the web – bypassing any filters/caching/auditing/scanning
> that you've got set up."
>
>
>
> This is exactly my point.
>
>
>
> If they connect and get an internal IP, with an internal default gateway,
> all traffic to the outside, should be routed through the inside.....
>
>
>
> "unless the destination address is the internal network, why SHOULD it
> send it via the internal interface? "  This is also a good point.  I know
> this worked fine when we had an Astaro firewall.  The thought is that the
> Astaro is Linux, and Linux would note that it was an internal IP and simply
> send it out the internal interface.
>
>
>
>
>
> Chad Schneider
> Systems Engineer
> ThedaCare IT
> 920-735-7615
>
> >>> On 4/30/2008 at 8:33 AM, <andrew.wood@xxxxxxxxxxxxxxxx> wrote:
>
> I'd have thought that if the routing address on your internal interface
> was correct,  that all traffic going through the CAG should head through the
> internal interface – and then be routed out through the normal channels for
> internal network traffic to the internet (which is unlikely to be the CAG)
>
>
>
> Otherwise, someone connecting on the external interface is being routed
> straight out onto the web – bypassing any filters/caching/auditing/scanning
> that you've got set up.
>
>
>
> This doesn't help Chad mind – other than agreeing with him that whats
> happening sounds wrong
>
>
>
> a.
>
>
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Berny Stapleton
> *Sent:* 30 April 2008 14:26
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: WHY
>
>
>
> OK, maybe this is just me and my limited experience with CAG...
>
> A VPN session which I presume is a connection from the internet (External)
> to the CAG, the CAG being a gateway device between external internet and
> internal network, when you bring up a VPN session, or in this case I presume
> IPSEC policy between the two devices (Client PC and the CAG) which would
> give you a IPSEC policy to the CAG and any traffic you send to it through
> the IPSEC policy would end up on it's local routing table. At which point it
> has to make a routing decision about where to send the traffic, it's an
> external address so therefore it would send it to the external interface and
> therefore external address.
>
> That seems logical to me. My question to you is, unless the destination
> address is the internal network, why SHOULD it send it via the internal
> interface? My only educated guess on this one is that you used part of your
> INTERNAL address space for the addresses you assigned to the CAG for it to
> hand out to clients, when as far as I can see, the clients should have been
> treated or thought of as DMZ interfaces / connections.
>
> This is just what I am thinking about having done firewall admin before.
>
> If I am wrong on this one, and completley off base, please let me know, my
> experiece with CAG is limited.
>
> Berny
>
> 2008/4/30 Chad Schneider (IT) <Chad.M.Schneider@xxxxxxxxxxxxx>:
>
> Does a VPN session to the CAG, route external bound internet traffic
> through the CAG external interface, rather than through the CAG Internal
> interface?
>
>
>
> I am watching the traffic, from our CAG internal IP range, when making a
> request to google.com, the traffic goes out the CAG INT0(External).
>
>
>
>
>
> Chad Schneider
> Systems Engineer
> ThedaCare IT
> 920-735-7615
>
>
>
>
>

Other related posts: