firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Issue with replacing SonicWall VPN with Cisco ASA VPN
devices (Michael Cox)
2. Re: Issue with replacing SonicWall VPN with Cisco ASA VPN
devices (Michael Cox)
3. Re: VPN Issue with Certs and fragmentation
(Bell Simon (RBNA/CIT1.12-Sbd))
4. Re: Issue with replacing SonicWall VPN with Cisco ASA
VPNdevices (Behm, Jeffrey L.)
5. Re: Issue with replacing SonicWall VPN with Cisco ASA VPN
devices (Brett Cunningham)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Sep 2007 09:25:33 -0500
From: Michael Cox <michael@wanderingbark.net>
Subject: Re: [fw-wiz] Issue with replacing SonicWall VPN with Cisco
ASA VPN devices
To: firewall-wizards@listserv.icsalabs.com
Cc: "Behm, Jeffrey L." <BehmJL@bv.com>
Message-ID: <200709260925.33880.michael@wanderingbark.net>
Content-Type: text/plain; charset="iso-8859-1"
For clarification, are there clients connecting to the 5505's, or is it
just a site-to-site setup?
In any case, what you want to do should be possible. When you define the
ACL for what traffic goes down the tunnel from the branch to the hub,
simply do "permit ip <LAN network address> <LAN netmask> any". Reverse
this on the hub.
I'm stumped as to why they think this is a security issue.
Maybe TAC didn't understand what you want to do (or maybe I don't).
Regards,
Michael
On Tuesday 25 September 2007 09:03, Behm, Jeffrey L. wrote:
> Hello Wizards,
>
> Our network team is replacing the client's SonicWall devices with
> Cisco ASA 5505 (remote office) and 5520 (HQ) devices. The SonicWall
> devices were basically used as VPN endpoints in remote offices to be
> concentrated back to the corporate HQ. All traffic not destined for
> the local LAN in the remote offices was sent to the corporate office
> via the "Route all traffic through this SA" functionality in the
> SonicWall. This worked well for the environment, but now there is the
> need to replace these devices, and Cisco ASA devices have been
> chosen.
>
> They are now trying to duplicate that functionality via the Cisco
> devices, but in talking with Cisco TAC, they say such a configuration
> is not possible, and even if it were, it would not be a security best
> practice. Implementation of the Cisco device has broken all Internet
> connectivity from the remote offices, since the only traffic allowed
> out to/from the Internet is through HQ (with the exception of the
> site to site VPN traffic to allow connectivity between remote offices
> and HQ). Remote offices can see everything on the HQ LAN, because the
> Cisco device is configured with IP information that allows it to
> route traffic to HQ.
>
> I can see some of Cisco's arguments regarding it not being a security
> best practice, but in the scenario of centralized management and
> monitoring of Internet-bound traffic, has anyone successfully
> configured the Cisco devices to mimic the "Route all traffic through
> this SA" functionality present in the SonicWall devices? I understand
> they could open up the Cisco devices to allow traffic out from each
> office, but that would require monitoring every remote office, and
> deviates from the centralized monitoring/management path we are
> currently traversing. I haven't personally been involved in this
> implementation, but was approached by the network team due to my
> security background, so I can get more details from the network team
> if necessary.
>
> We are simply trying to mimic in the Cisco devices the "Route all
> traffic through this SA" functionality present in the SonicWall
> devices.
>
> Thoughts?
>
> Jeff
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
Message: 2
Date: Wed, 26 Sep 2007 09:48:39 -0500
From: Michael Cox <michael@wanderingbark.net>
Subject: Re: [fw-wiz] Issue with replacing SonicWall VPN with Cisco
ASA VPN devices
To: firewall-wizards@listserv.icsalabs.com
Cc: "Behm, Jeffrey L." <BehmJL@bv.com>
Message-ID: <200709260948.39457.michael@wanderingbark.net>
Content-Type: text/plain; charset="iso-8859-1"
On Tuesday 25 September 2007 19:20, Brett Cunningham wrote:
> Never used a SonicWall, but you should be able to tunnel all traffic
> through the vpn. To match the traffic, it's as simple as:
>
> (on roho asa) access-list to_hq ip any any
> (on hq asa) access-list to_ro ip any any
>
> Nothing else is required provided that the vpn is up and the subnet
> of the roho lan is different than the hq subnet.
>
Since there is one hub and multiple spokes, you can't do "ip any any".
You need to specify the subnet(s) for each spoke in its respective acl.
Also, if the spokes need to talk to each other, don't forget
the "same-security-traffic intra-interface" command. I'm assuming here
that there is a single Internet interface for all VPN traffic on the
hub.
Regards,
Michael
> On 9/25/07, Behm, Jeffrey L. <BehmJL@bv.com> wrote:
> > Hello Wizards,
> >
> > Our network team is replacing the client's SonicWall devices with
> > Cisco ASA 5505 (remote office) and 5520 (HQ) devices. The SonicWall
> > devices were basically used as VPN endpoints in remote offices to
> > be concentrated back to the corporate HQ. All traffic not destined
> > for the local LAN in the remote offices was sent to the corporate
> > office via the "Route all traffic through this SA" functionality in
> > the SonicWall. This worked well for the environment, but now there
> > is the need to replace these devices, and Cisco ASA devices have
> > been chosen.
> >
> > They are now trying to duplicate that functionality via the Cisco
> > devices, but in talking with Cisco TAC, they say such a
> > configuration is not possible, and even if it were, it would not be
> > a security best practice. Implementation of the Cisco device has
> > broken all Internet connectivity from the remote offices, since the
> > only traffic allowed out to/from the Internet is through HQ (with
> > the exception of the site to site VPN traffic to allow connectivity
> > between remote offices and HQ). Remote offices can see everything
> > on the HQ LAN, because the Cisco device is configured with IP
> > information that allows it to route traffic to HQ.
> >
> > I can see some of Cisco's arguments regarding it not being a
> > security best practice, but in the scenario of centralized
> > management and monitoring of Internet-bound traffic, has anyone
> > successfully configured the Cisco devices to mimic the "Route all
> > traffic through this SA" functionality present in the SonicWall
> > devices? I understand they could open up the Cisco devices to allow
> > traffic out from each office, but that would require monitoring
> > every remote office, and deviates from the centralized
> > monitoring/management path we are currently traversing. I haven't
> > personally been involved in this implementation, but was approached
> > by the network team due to my security background, so I can get
> > more details from the network team if necessary.
> >
> > We are simply trying to mimic in the Cisco devices the "Route all
> > traffic through this SA" functionality present in the SonicWall
> > devices.
> >
> > Thoughts?
> >
> > Jeff
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards@listserv.icsalabs.com
> > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
Message: 3
Date: Wed, 26 Sep 2007 10:41:41 -0500
From: "Bell Simon (RBNA/CIT1.12-Sbd)" <Simon.Bell@us.bosch.com>
Subject: Re: [fw-wiz] VPN Issue with Certs and fragmentation
To: "John Kougoulos" <koug@intracom.gr>, "Firewall Wizards Security
Mailing List" <firewall-wizards@listserv.cybertrust.com>
Message-ID:
<46BC68B9582AE944BE04A833806C85A5011B7852@mtpmail03.us.bosch.com>
Content-Type: text/plain; charset="us-ascii"
This issue is really frustrating me and I'm sure it's frustrating our
customers. I can't get our CA to issue a smaller cert, we're using
1024bit, so I'm gonna self sign one or setup our own CA to test this
theory. Here is a list of things and scenarios I've tested, some work
some don't:
Usually directly connecting to the broadband modem works - however in
public hotspots/hotels this isn't a viable solution.
If wired works and wireless does not, typically dropping down to WEP
from WPAx works.
Sometimes sending the CA chain (profile option) works.
Changing the MTU on the client had no effect
Changing the MTU on the public interface of the ASA had no effect
Many times a firmware upgrade on the router fixes the problem
I've also seen a doc on Dells site referring to a VLAN priority support:
http://support.dell.com/support/topics/global.aspx/support/dsn/en/docume
nt?c=us&docid=152D7D67033477DFE0401E0A5517188F&journalid=38B395C7FBD511D
ABA931F114956E124&l=en&s=gen
I'd really like to find a change that could be made on our ASAs that
would affect all our users. Working with each individual problem is a
real headache.
Any other suggestions or advice would be welcomed.
Simon
-----Original Message-----
From: John Kougoulos [mailto:koug@intracom.gr]
Sent: Wednesday, September 12, 2007 9:49 AM
To: Bell Simon (RBNA/CIT1.12)
Subject: RE: [fw-wiz] VPN Issue with Certs and fragmentation
> Thanks for the reply. We're using two pair of Clustered ASAs. We're
> pretty confident that the issue is client side but are still don't
> really understand why a Pre-Shared Key tunnel works on networks where
a
> certs fail.
it works because when you use cert mode, during IKE nego, the server
sends
the certificate to the client for validation. The certificate doesn't
fit
in the 1500 byte packet, therefore it fragments it.
if you don't use cert, the packet is much smaller than 1500bytes.
I think that if you use a certificate with smaller key size it might
work
too.
I had also an issue where the traffic to a vpn concentrator was
travelling
through an ASA and I had to use the "exceed-mss allow" workaround, so
that
I can run IPsec over TCP through an ASA, I don't know if this is the
issue
with your installation
Best Regards,
John.
PS. If you find a solution, please post it.... I'm still in the VPN
concentrator boxes but soon I'll have to use the ASA too.
> -----Original Message-----
> From: John Kougoulos [mailto:koug@intracom.gr]
> Sent: Wednesday, September 12, 2007 3:09 AM
> To: Bell Simon (RBNA/CIT1.12)
> Cc: firewall-wizards@listserv.cybertrust.com
> Subject: Re: [fw-wiz] VPN Issue with Certs and fragmentation
>
> I've seen this in Cisco VPN concentrators when using IPsec over TCP
with
> "Mutual Authentication". what platform are you using for vpn
> termination?
>
> Note also that in one case, while I was debugging this issue, I found
> out that the problem was an issue of double fragmentation and a broken
> DSL
> modem in the path.
>
> What was happenning:
>
> a. VPN concentrator replies with a 1500 byte packet, frag , no DF
> b. Packet goes to the ISP router which fragments it to 1492 + 8 to
pass
> through the ADSL line
> c. DSL Modem/router (even on bridging only mode) drops the 8 (+20)
byte
> packet
>
> In this case, I changed the MTU of the VPN concentrator to 1492 and
> everything worked fine.
>
> --koug
>
> On Tue, 11 Sep 2007, Bell Simon (RBNA/CIT1.12) wrote:
>
>> We occasionally have customers call in reporting that they're never
>> prompted for credentials when attempting to connect to the VPN. This
>> happens most often when they're at a hotel/public hotspot. However,
if
>> they use a profile based on a preshared key instead of a cert
>> authentication, they connection works w/o issue. I've captured
traffic
>> off a failed user and it looks like during a cert auth IPSec tunnel
>> there's a fair amount of packet fragmentation. I'm guessing then that
> a
>> router in-between is probably just dropping those packets causing
> phase1
>> to fail. Has anyone else seen something similar to this? I'm thinking
>> dropping the MTU on either our public interface or on the client
>> directly.
>>
>> Any other suggestions shared experiences would be great,
>>
>> Simon
>> _______________________________________________
>> firewall-wizards mailing list
>> firewall-wizards@listserv.icsalabs.com
>> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>>
>
------------------------------
Message: 4
Date: Wed, 26 Sep 2007 11:18:56 -0500
From: "Behm, Jeffrey L." <BehmJL@bv.com>
Subject: Re: [fw-wiz] Issue with replacing SonicWall VPN with Cisco
ASA VPNdevices
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.cybertrust.com>
Message-ID:
<0C3670BC9169B244AA6E7B2E436180D196385B@TSMC-MAIL-04.na.bvcorp.net>
Content-Type: text/plain; charset="us-ascii"
No clients connecting...it's site-to-site only.
> For clarification, are there clients connecting to the 5505's, or is
it just a site-to-site setup?
------------------------------
Message: 5
Date: Wed, 26 Sep 2007 11:20:12 -0500
From: "Brett Cunningham" <cssniper22@gmail.com>
Subject: Re: [fw-wiz] Issue with replacing SonicWall VPN with Cisco
ASA VPN devices
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<63e59b100709260920i3f58e8f0wd0aacfdfa58f25a5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thanks for the correction Michael, that's what I meant but not what I said.
I don't think it would be a security issue... I'd be interested to
hear if anyone can come up with an idea of why it would be.
On 9/26/07, Michael Cox <michael@wanderingbark.net> wrote:
> For clarification, are there clients connecting to the 5505's, or is it
> just a site-to-site setup?
>
> In any case, what you want to do should be possible. When you define the
> ACL for what traffic goes down the tunnel from the branch to the hub,
> simply do "permit ip <LAN network address> <LAN netmask> any". Reverse
> this on the hub.
>
> I'm stumped as to why they think this is a security issue.
>
> Maybe TAC didn't understand what you want to do (or maybe I don't).
>
> Regards,
> Michael
>
> On Tuesday 25 September 2007 09:03, Behm, Jeffrey L. wrote:
> > Hello Wizards,
> >
> > Our network team is replacing the client's SonicWall devices with
> > Cisco ASA 5505 (remote office) and 5520 (HQ) devices. The SonicWall
> > devices were basically used as VPN endpoints in remote offices to be
> > concentrated back to the corporate HQ. All traffic not destined for
> > the local LAN in the remote offices was sent to the corporate office
> > via the "Route all traffic through this SA" functionality in the
> > SonicWall. This worked well for the environment, but now there is the
> > need to replace these devices, and Cisco ASA devices have been
> > chosen.
> >
> > They are now trying to duplicate that functionality via the Cisco
> > devices, but in talking with Cisco TAC, they say such a configuration
> > is not possible, and even if it were, it would not be a security best
> > practice. Implementation of the Cisco device has broken all Internet
> > connectivity from the remote offices, since the only traffic allowed
> > out to/from the Internet is through HQ (with the exception of the
> > site to site VPN traffic to allow connectivity between remote offices
> > and HQ). Remote offices can see everything on the HQ LAN, because the
> > Cisco device is configured with IP information that allows it to
> > route traffic to HQ.
> >
> > I can see some of Cisco's arguments regarding it not being a security
> > best practice, but in the scenario of centralized management and
> > monitoring of Internet-bound traffic, has anyone successfully
> > configured the Cisco devices to mimic the "Route all traffic through
> > this SA" functionality present in the SonicWall devices? I understand
> > they could open up the Cisco devices to allow traffic out from each
> > office, but that would require monitoring every remote office, and
> > deviates from the centralized monitoring/management path we are
> > currently traversing. I haven't personally been involved in this
> > implementation, but was approached by the network team due to my
> > security background, so I can get more details from the network team
> > if necessary.
> >
> > We are simply trying to mimic in the Cisco devices the "Route all
> > traffic through this SA" functionality present in the SonicWall
> > devices.
> >
> > Thoughts?
> >
> > Jeff
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards@listserv.icsalabs.com
> > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 17, Issue 22
************************************************
No comments:
Post a Comment