[THIN] Re: WHY

As Steve says – I’d check your gateways in the first instance – might be that 
the user’s gateway is incorrect / badlyconfigured and its redirecting traffic 
incorrectly.

 

From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of 
Chad Schneider (IT)
Sent: 30 April 2008 16:09
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: WHY

 

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: