From LISTSERV at LISTS.SECURITYFOCUS.COM Mon Sep 11 09:00:50 2000 From: LISTSERV at LISTS.SECURITYFOCUS.COM (L-Soft list server at SecurityFocus.com (1.8d)) Date: Mon, 11 Sep 2000 06:00:50 -0700 Subject: Renewal of your subscription to the VPN list Message-ID: <20000911130050.8F03F1F165@lists.securityfocus.com> Mon, 11 Sep 2000 06:00:50 Your subscription to the VPN list is due for renewal. If you wish to remain subscribed to VPN, please issue the following command to LISTSERV at LISTS.SECURITYFOCUS.COM at your earliest convenience: CONFIRM VPN You will be automatically removed from the list if you do not send a CONFIRM command within the next 14 days. PS: In order to facilitate the task, this message has been specially formatted so that you only need to forward it back to LISTSERV at LISTS.SECURITYFOCUS.COM to have the command executed. Note that while the formats produced by the forwarding function of most mail packages are supported, replying will seldom work, so make sure to forward and not reply. ------------------------------------------------------------------------- // JOB CONFIRM VPN // EOJ From martinjc at LUCENT.COM Thu Sep 7 12:51:00 2000 From: martinjc at LUCENT.COM (Martin, Jose Carlos (Jose)) Date: Thu, 7 Sep 2000 18:51:00 +0200 Subject: ipsec+nat Message-ID: <4AB6F04F07BBD21191180008C70DD48F050C37DA@sp0002exch001u.es.lucent.com> Hello all, I would like to know if NAT and IPSEC are compatible when using ESP (both tunnel and transport mode). Thanks in advance, Jos? Carlos VPN is sponsored by SecurityFocus.COM From vampier at MAC.COM Thu Sep 7 23:22:02 2000 From: vampier at MAC.COM (Andrew Chen) Date: Thu, 7 Sep 2000 23:22:02 -0400 Subject: ppp over ssh? Message-ID: I want a quick, cheap, secure, but not necessarily fast, VPN. I am planning on using PPP over SSH(SSL, actually) and then messing with some Linux routing tools (iproute and ipchains) to assemble this. Is there anything flawed in my idea? If not, is performance the only reason why not everyone is using this as their VPN solution? -- Andrew VPN is sponsored by SecurityFocus.COM From Andrew.Fletcher at TAYWOOD.CO.UK Sat Sep 9 07:52:50 2000 From: Andrew.Fletcher at TAYWOOD.CO.UK (Andrew.Fletcher at TAYWOOD.CO.UK) Date: Sat, 9 Sep 2000 12:52:50 +0100 Subject: vpn Message-ID: Problem: I have a point to point IPSec VPN configured on Cisco 1720 Routers (IOS Version 12.0(2a)T1). The VPN appears to be funcioning normally for all protocols except for HTTP. Remote Users connecting to Microsoft IIS/4.0 (NT4.0 SP5) websites fail with a timeout, however connection to a Unix Appache 1.3.1 works fine. On comparing protocol analyser traces the only apparent difference is the frame size negotiated in the TCP Header. On IIS4, TCP sets mss to 1460. On Appache mss is set to 512. I suspect the problem maybe due to IP fragmentation. Any ideas would be greatly appreciated. Additional info: On the remote network we also have a Shiva remote access server. When I dial into this and connect through the VPN to IIS4 website, this works fine. Again the network analyser shows the TCP mss set to 536 bytes which appears to be acceptable. Regards Andrew Andrew Fletcher IT Operations Taylor Woodrow Construction Limited 345 Ruislip Road, Southall, Middlesex, UB1 2QX. Tel: +44 (0)20.8575.4070 Fax: +44 (0)870.160.3814 mailto:andrew.fletcher at taywood.co.uk ************************************************** The information contained in this email is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. If you have received this email in error please note that any review, retransmission, copying, dissemination or other use of, or taking of any action in reliance upon its contents is prohibited. If you are not an intended recipient, Please delete the material from any computer that may have it and contact the Taylor Woodrow I.T Helpdesk on +44 (0)20 8575 4811, or send an email to helpdesk at taywood.co.uk. Thank you for your co-operation. The contents of an attachment to this email may contain software viruses which could damage your computer system. We cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: BDY.RTF Type: application/rtf Size: 1488 bytes Desc: not available Url : http://lists.shmoo.com/pipermail/vpn/attachments/20000909/aff22a46/attachment.rtf From tbird at PRECISION-GUESSWORK.COM Mon Sep 11 13:39:29 2000 From: tbird at PRECISION-GUESSWORK.COM (Tina Bird) Date: Mon, 11 Sep 2000 12:39:29 -0500 Subject: list quiet Message-ID: Hi everyone -- I have now returned from my vacation, so the VPN list should be returning to normal. If you have submitted a message in the past week that didn't get posted, please resend it. Sorry for the disruption -- tbird VPN: http://kubarb.phsx.ukans.edu/~tbird/vpn.html life: http://kubarb.phsx.ukans.edu/~tbird work: http://www.counterpane.com VPN is sponsored by SecurityFocus.COM From Kevin_Butters at NAI.COM Thu Sep 7 16:23:52 2000 From: Kevin_Butters at NAI.COM (Butters, Kevin) Date: Thu, 7 Sep 2000 13:23:52 -0700 Subject: Altsubject name question Message-ID: One, what purpose does the Altsubject name server on a X.509 Certificate server? Two, is Altsubject name = = Common Name? Kevin Butters VPN is sponsored by SecurityFocus.COM From jsdy at COSPO.OSIS.GOV Mon Sep 11 15:31:57 2000 From: jsdy at COSPO.OSIS.GOV (Joseph S D Yao) Date: Mon, 11 Sep 2000 15:31:57 -0400 Subject: ppp over ssh? In-Reply-To: ; from vampier@MAC.COM on Thu, Sep 07, 2000 at 11:22:02PM -0400 References: Message-ID: <20000911153156.X15296@washington.cospo.osis.gov> On Thu, Sep 07, 2000 at 11:22:02PM -0400, Andrew Chen wrote: > I want a quick, cheap, secure, but not necessarily fast, VPN. I am > planning on using PPP over SSH(SSL, actually) and then messing with > some Linux routing tools (iproute and ipchains) to assemble this. > > Is there anything flawed in my idea? If not, is performance the only > reason why not everyone is using this as their VPN solution? Enough others are doing this that there is, I believe, a HOWTO on this out there somewhere. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM From jsdy at COSPO.OSIS.GOV Mon Sep 11 15:57:53 2000 From: jsdy at COSPO.OSIS.GOV (Joseph S D Yao) Date: Mon, 11 Sep 2000 15:57:53 -0400 Subject: vpn In-Reply-To: ; from Andrew.Fletcher@taywood.co.uk on Sat, Sep 09, 2000 at 12:52:50PM +0100 References: Message-ID: <20000911155753.A15296@washington.cospo.osis.gov> On Sat, Sep 09, 2000 at 12:52:50PM +0100, Andrew.Fletcher at taywood.co.uk wrote: > Problem: > I have a point to point IPSec VPN configured on Cisco 1720 Routers (IOS > Version 12.0(2a)T1). The VPN appears to be funcioning normally for all > protocols except for HTTP. Remote Users connecting to Microsoft IIS/4.0 > (NT4.0 SP5) websites fail with a timeout, however connection to a Unix > Appache 1.3.1 works fine. On comparing protocol analyser traces the only > apparent difference is the frame size negotiated in the TCP Header. On > IIS4, TCP sets mss to 1460. On Appache mss is set to 512. I suspect the > problem maybe due to IP fragmentation. Any ideas would be greatly > appreciated. Probably exactly right. The packet size must be set smaller [in MSW-NT, I don't think IIS controls this] to be able to fit "through" the tunnel. MSW-NT may not be accepting the requests to fragment its packets. We have had similar problems with MSW-NT mail servers. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM From bob.duncan at SECUREINFO.COM Mon Sep 11 15:36:06 2000 From: bob.duncan at SECUREINFO.COM (Bob Duncan) Date: Mon, 11 Sep 2000 14:36:06 -0500 Subject: ipsec+nat Message-ID: Jose, I have a white paper titled "Creating a VPN between a Cisco router and a Checkpoint Firewall using manual IPSEC". It mentions using IPSEC with NAT. It states that NAT is processed before crypto, so you have to create ACLs so that NAT traffic will fail so that the router will encrypt it. The white paper can be found at www.imtek.com/IPSec.html. I don't know if this is what you were looking for but I hope it helps. Bob Duncan SecureInfo Corporation (210) 738-1196 www.esecureinfo.com -----Original Message----- From: Martin, Jose Carlos (Jose) [mailto:martinjc at LUCENT.COM] Sent: Thursday, September 07, 2000 11:51 AM To: VPN at SECURITYFOCUS.COM Subject: ipsec+nat Hello all, I would like to know if NAT and IPSEC are compatible when using ESP (both tunnel and transport mode). Thanks in advance, Jos? Carlos VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From evyncke at CISCO.COM Mon Sep 11 16:36:32 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Mon, 11 Sep 2000 22:36:32 +0200 Subject: Altsubject name question In-Reply-To: Message-ID: <4.2.0.58.20000911223543.00aca410@brussels.cisco.com> At 13:23 07/09/2000 -0700, Butters, Kevin wrote: >One, what purpose does the Altsubject name server on a X.509 Certificate >server? To put something which is not a plain distinguished name (which is the type of SubjectName). AltSubjectName can be anything including FQDN and IP addresses -eric >Two, is Altsubject name = = Common Name? > >Kevin Butters > >VPN is sponsored by SecurityFocus.COM Eric Vyncke Senior Consulting Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke at cisco.com Mobile: +32-75-312.458 PGP Key available on request -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000911/6681de80/attachment.htm From sandy at STORM.CA Mon Sep 11 16:20:25 2000 From: sandy at STORM.CA (Sandy Harris) Date: Mon, 11 Sep 2000 16:20:25 -0400 Subject: ppp over ssh? References: Message-ID: <39BD3E89.B0B8BA49@storm.ca> Andrew Chen wrote: > > I want a quick, cheap, secure, but not necessarily fast, VPN. I am > planning on using PPP over SSH(SSL, actually) and then messing with > some Linux routing tools (iproute and ipchains) to assemble this. The docs for the Linux IPSEC implementation FreeS/WAN have links to other Linux VPN solutions, including one that is almost exactly as you describe. http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/WWWref.html#alternatives > Is there anything flawed in my idea? If not, is performance the only > reason why not everyone is using this as their VPN solution? Interoperability is one other. IPSEC is available for everything from routers to IBM mainframes. VPN is sponsored by SecurityFocus.COM From rgm at ICSA.NET Mon Sep 11 16:45:49 2000 From: rgm at ICSA.NET (Robert Moskowitz) Date: Mon, 11 Sep 2000 16:45:49 -0400 Subject: ppp over ssh? In-Reply-To: Message-ID: <4.3.2.7.2.20000911164306.00e43c20@homebase.htt-consult.com> At 11:22 PM 9/7/2000 -0400, Andrew Chen wrote: >I want a quick, cheap, secure, but not necessarily fast, VPN. I am >planning on using PPP over SSH(SSL, actually) and then messing with >some Linux routing tools (iproute and ipchains) to assemble this. > >Is there anything flawed in my idea? If not, is performance the only >reason why not everyone is using this as their VPN solution? Below is a way to do it. Then following that is a security concern by a colleague on this method.... ================================================================= I reformatted this for non-web readablity: VPN with SSH by Mark Richards [richard at ecf.utoronto.ca] - Skill: B - Jul 01, 2000 One computer, which I'll call the server, runs sshd (the ssh daemon or service: it handles ssh logins). The other computer (the client) connects to the server using ssh. A ppp session is established over the ssh connection. This can be accomplished using the following command: /usr/sbin/pppd noauth pty "ssh server -l pppuser '/usr/sbin/pppd notty noauth 192.168.0.1:192.168.0.2'" 192.168.0.2:192.168.0.1 Some notes: 1.On the server, a user account must be able to start pppd. Normally only the root (superuser) can do this, but that can be changed. In a production system I would recommend changing it; this helps limit damage in case the client is compromised; then the hacker doesn't automatically get free root access to the server. 2.On the client, the user account must be able to start pppd,. and must be able to log into the remote machine as the above user. It probably doesn't matter if this user is root. This does the following: - Launches pppd (the PPP daemon) on the client side, with no authentication required by the server (ssh handles authentication), using a virtual terminal (that's the pty part). The pty uses the ssh command to connect. More on that in a sec. The last argument is the ip addresses. That tells pppd to use 192.168.0.2 for its own address, and to expect the server to use 192.168.0.1. The ssh part says : Launch ssh, log into host "router" as root. don't give me a terminal screen but instead run the command '/usr/sbin/pppd notty noauth 192.168.0.1:192.168.0.2'. This command means start pppd, don't require authentication, use these ip addresses (as above) and the "notty" part says "don't whine about not having a real terminal, just use the virtual terminal that sshd provides" How does this work? Well, pppd uses ASCII text to transfer the information. The Unix virtual terminals are good at that. sshd allocates a virtual terminal on the server when you connect, and the pppd command on the client allocates one there. The two pppds then established their connection over the ssh connection. ssh is secure; the entire session is encrypted, including the username and password, and can even be configured to not use passwords (using public-key/private-key things, etc). I recommend setting up a key method (ie put a public key on the client computer) so that the client can log on to the server automatically, without asking the user for a password. This is why you don't want the server user to be root, since the logon would be automatic. How is performance? ssh is basically software encryption, and both ssh and pppd are user-space programs. This means that they may perform slightly slower than a kernel space module; however it usually doesn't matter much. The PPP network interface created by pppd is actually kernel space, so that part is fast all the time. The only real problem is that the CPU is involved in encrypting all the data over the ssh connection. On computers with high cpu usage, this could be a problem; if ssh can't transmit the data fast enough, pppd might figure the link is dead. The connection could be re-established by adding a "persist" argument to the client command line, but that would be a painful work-around. However, for a software VPN, it's totally secure and totally free. For a free SSH client and server for most Unix, check out www.openssh.com. What good is it? Well, you can use it to play LAN games that don't work on the Internet; you can securely share files (either Windows style or Unix style); you can basically treat the two computers as if they were connected by a wire instead of by the internet. ========================================================= It's a decent hack if you don't have IPsec. The script as presented has a serious security hole, in that the client is specifying its own IP address... Apart from the fact that it's Linux-specific (and maybe some of the free BSDs), you also need to play games with routing if you want to reach other hosts via your sshd/pppd server. And -- unlike decent IPsec implementations -- there's no rejection of other incoming packets that didn't go through the tunnel. However, you may be able to hack that up via ipchains (on Linux) or ipf (on *BSD). Robert Moskowitz ICSA.net (248) 968-9809 Fax: (248) 968-2824 rgm at icsa.net There's no limit to what can be accomplished if it doesn't matter who gets the credit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000911/748e76c4/attachment.htm From Ole.Vik at CONNECT.NO Mon Sep 11 18:05:56 2000 From: Ole.Vik at CONNECT.NO (Ole Vik) Date: Tue, 12 Sep 2000 00:05:56 +0200 Subject: ipsec+nat Message-ID: <904078305Ole.Vik@connect.no> Yes, they are compatible in some routers (for example Netopia). Cisco does not support this. Have never found out why. In all cases the router needs to be IPsec passthough aware. That is it has to have special code to recognize IPsec packets. When a router runs in NAT mode, it needs to do address translation for machines on the LAN side of the router. The encrypted packets needs to be modified in order for this to work. -- Ole Vik, Connect AS, Blakstadmarka 26, 1386 Asker, Norway. Telephone +47-66 90 23 00. Telefax +47-66 90 23 05. On torsdag 7. september 2000 18:51, Martin, Jose Carlos wrote: >Hello all, > >I would like to know if NAT and IPSEC are compatible when using ESP (both >tunnel and transport mode). > >Thanks in advance, > >Jos? Carlos > >VPN is sponsored by SecurityFocus.COM > VPN is sponsored by SecurityFocus.COM From bet at RAHUL.NET Mon Sep 11 18:04:06 2000 From: bet at RAHUL.NET (Bennett Todd) Date: Mon, 11 Sep 2000 18:04:06 -0400 Subject: ppp over ssh? In-Reply-To: ; from vampier@MAC.COM on Thu, Sep 07, 2000 at 11:22:02PM -0400 References: Message-ID: <20000911180406.M13561@oven.com> 2000-09-07-23:22:02 Andrew Chen: > I want a quick, cheap, secure, but not necessarily fast, VPN. I am > planning on using PPP over SSH(SSL, actually) and then messing with > some Linux routing tools (iproute and ipchains) to assemble this. First note, ssh and ssl have essentially nothing to do with each other, aside from the fact that they're both fairly modern crypto protocols, and so are built from the same building blocks. But ssh is an rsh/rlogin/rcp replacement that also does port forwarding, while ssl is a lower-level protocol, which provides a crypto equivalent to the socket abstraction for TCP connections. PPP could be tunneled over either, with similar characteristics. > Is there anything flawed in my idea? If not, is performance the > only reason why not everyone is using this as their VPN solution? A fair number of people do it. As long as you confine yourself to running over a LAN, it ought to work pretty well. As soon as you try and run over the internet, it'll hose pretty badly. See for why. If you want something lightweight, simple, and fast, check out , or (the latter by the author of the previously mentioned paper on tcp over tcp). -Bennett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.shmoo.com/pipermail/vpn/attachments/20000911/b730b2c8/attachment.pgp From John.Fulmer at LEVEL3.COM Mon Sep 11 18:27:55 2000 From: John.Fulmer at LEVEL3.COM (John Fulmer) Date: Mon, 11 Sep 2000 16:27:55 -0600 Subject: ppp over ssh? References: <39BD3E89.B0B8BA49@storm.ca> Message-ID: <39BD5C6B.FAAF7731@level3.com> Sandy Harris wrote: > > Andrew Chen wrote: > > Is there anything flawed in my idea? If not, is performance the only > > reason why not everyone is using this as their VPN solution? > > Interoperability is one other. IPSEC is available for everything from > routers to IBM mainframes. Robustness is another. Without a certain amount of work, ppp via ssh (or ssl) has no easy way to reestablish itself if an excessive amount of packets are dropped, and the connection is broken. It's probably doable, just not real easy. VPN is sponsored by SecurityFocus.COM From evyncke at CISCO.COM Tue Sep 12 03:43:22 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Tue, 12 Sep 2000 09:43:22 +0200 Subject: ipsec+nat In-Reply-To: <904078305Ole.Vik@connect.no> Message-ID: <4.2.0.58.20000912093732.00ab3bd0@brussels.cisco.com> Hummm... First check my email address to see my affiliation and possible bias ;-) On paper, IPSec ESP and NAT work fine. On IOS routers, they also work fine. You must just be aware of the order of operation to get the right configuration: - encrypting router: input ACL, routing, switching, ouput ACL, NAT, IPSec, (and possibly again output ACL), queueing (QoS) - decrypting router: input ACL, IPSec (and possibly again input ACL), NAT, routing, switching, output ACL - intermediate router: they do not care The combination ESP and NAT is heavily used in a couple of existing networks (e.g. for extranet VPN). Caveat #1: so the IPSec configuration must use the NAT'ed address for its configuration (mainly for the crypto ACL) Caveat #2: as you know, there are two kinds of NAT: plain NAT mapping one IP address to one IP address and PAT (Port Address Translation) where all 'internal' IP addresses are mapped into a single 'external' IP address. Using PAT will currently break both IPSec and IKE in IOS. Hope this helps -eric At 00:05 12/09/2000 +0200, Ole Vik wrote: >Yes, they are compatible in some routers (for example Netopia). Cisco does not support this. Have never found out why. In all cases the router needs to be IPsec passthough aware. That is it has to have special code to recognize IPsec packets. When a router runs in NAT mode, it needs to do address translation for machines on the LAN side of the router. The encrypted packets needs to be modified in order for this to work. >-- >Ole Vik, Connect AS, Blakstadmarka 26, 1386 Asker, Norway. >Telephone +47-66 90 23 00. Telefax +47-66 90 23 05. > >On torsdag 7. september 2000 18:51, Martin, Jose Carlos wrote: > >Hello all, > > > >I would like to know if NAT and IPSEC are compatible when using ESP (both > >tunnel and transport mode). > > > >Thanks in advance, > > > >Jos? Carlos > > > >VPN is sponsored by SecurityFocus.COM > > > >VPN is sponsored by SecurityFocus.COM Eric Vyncke Senior Consulting Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke at cisco.com Mobile: +32-75-312.458 PGP Key available on request VPN is sponsored by SecurityFocus.COM From mag at BUNUEL.TII.MATAV.HU Tue Sep 12 04:09:18 2000 From: mag at BUNUEL.TII.MATAV.HU (=?iso-8859-2?Q?Magos=E1nyi_=C1rp=E1d?=) Date: Tue, 12 Sep 2000 10:09:18 +0200 Subject: ppp over ssh? In-Reply-To: ; from vampier@MAC.COM on Thu, Sep 07, 2000 at 11:22:02PM -0400 References: Message-ID: <20000912100918.C30491@bunuel.tii.matav.hu> > I want a quick, cheap, secure, but not necessarily fast, VPN. I am > planning on using PPP over SSH(SSL, actually) and then messing with > some Linux routing tools (iproute and ipchains) to assemble this. > > Is there anything flawed in my idea? If not, is performance the only > reason why not everyone is using this as their VPN solution? I have written a HOWTO on ppp over ssh, but now I recommend you freeswan or pipsecd instead. (I better like pipsecd, it is simple enough for my little brain). In those days there were no robust VPN implementation for linux, now we have it. Reasons: The TCP flow control does not do good to your performance The reestablishment of the link can be problematic It is nontrivial to make all layers of the link 8 bit clean It is just a hack. Clever one (Hey, I made it!:), but still... The only reasons to use vpn over ssh now are the following: You cannot use ipsec with the other end (link or OS limitations) You have one tcp port to tunnel the data through You want to tunnel IPX or other braindamage And in these cases you might want to take a look at pptp. (Beware, pptp's protocol is broken, but wrapping it in ssl and turning off crypto in pptp itself may be lesser work than ppp over ssh). And if you want to tunnel a finite set of tcp ports, you can just use ssh, or one of the ssl wrappers. -- GNU GPL: csak tiszta forr?sb?l VPN is sponsored by SecurityFocus.COM From evyncke at CISCO.COM Tue Sep 12 03:36:49 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Tue, 12 Sep 2000 09:36:49 +0200 Subject: vpn In-Reply-To: Message-ID: <4.2.0.58.20000912092954.00b1c180@brussels.cisco.com> Andrew Your assumption is probably right. Due to increase header size with IPSec the 'real' MTU is probably around 1400. The issue with most NT applications is that they try to optimize the MSS by using the path MTU discovery process. This PMTU relies on setting the DF, Don't Fragment, bit and listening to ICMP message to reduce the MSS. With IPSec VPN, this scheme is quite often broken: 1) ICMP messages are usually stopped by router ACL or firewall or load balancing box, hence the NT will never received it. And, if NT keeps using DF + MSS=1460, all the traffic is dropped. There is a workaround requiring to disable PMTU in the NT registry 2) depending on your configuration, you may want to artificially reduce the MTU on the IPSec router which is close to the NT to let's say 1400; this will force an ICMP message to be generated. NB: depending on the exact configuration, there were some bugs in IOS prior to 12.1 regarding the handling of ICMP messages when it was issued by a router in the middle of the IPSec tunnel. So, you may want to update. Regards -eric At 12:52 09/09/2000 +0100, Andrew.Fletcher at TAYWOOD.CO.UK wrote: >Problem: >I have a point to point IPSec VPN configured on Cisco 1720 Routers (IOS >Version 12.0(2a)T1). The VPN appears to be funcioning normally for all >protocols except for HTTP. Remote Users connecting to Microsoft IIS/4.0 >(NT4.0 SP5) websites fail with a timeout, however connection to a Unix >Appache 1.3.1 works fine. On comparing protocol analyser traces the only >apparent difference is the frame size negotiated in the TCP Header. On >IIS4, TCP sets mss to 1460. On Appache mss is set to 512. I suspect the >problem maybe due to IP fragmentation. Any ideas would be greatly >appreciated. > >Additional info: >On the remote network we also have a Shiva remote access server. When I >dial into this and connect through the VPN to IIS4 website, this works >fine. Again the network analyser shows the TCP mss set to 536 bytes >which appears to be acceptable. > > >Regards > >Andrew > > >Andrew Fletcher >IT Operations >Taylor Woodrow Construction Limited >345 Ruislip Road, Southall, Middlesex, UB1 2QX. > >Tel: +44 (0)20.8575.4070 >Fax: +44 (0)870.160.3814 > >mailto:andrew.fletcher at taywood.co.uk > > > >************************************************** >The information contained in this email is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. If you have received this email in error please note that any review, retransmission, copying, dissemination or other use of, or taking of any action in reliance upon its contents is prohibited. If you are not an intended recipient, Please delete the material from any computer that may have it and contact the Taylor Woodrow I.T Helpdesk on +44 (0)20 8575 4811, or send an email to helpdesk at taywood.co.uk. Thank you for your co-operation. > >The contents of an attachment to this email may contain software viruses which could damage your computer system. We cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment. Eric Vyncke Senior Consulting Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke at cisco.com Mobile: +32-75-312.458 PGP Key available on request VPN is sponsored by SecurityFocus.COM From guy.raymakers at EDS.COM Tue Sep 12 04:29:55 2000 From: guy.raymakers at EDS.COM (Raymakers, Guy) Date: Tue, 12 Sep 2000 09:29:55 +0100 Subject: FW: Nortel extrant client for Win2K Message-ID: Hi alI, Quick question about the Nortel Extranet Client for Win2K. Does anyone know what the status is of this software, is it already released ? Thanks, Guy VPN is sponsored by SecurityFocus.COM From shope at ENERGIS-EIS.CO.UK Tue Sep 12 07:26:02 2000 From: shope at ENERGIS-EIS.CO.UK (Stephen Hope) Date: Tue, 12 Sep 2000 12:26:02 +0100 Subject: vpn Message-ID: <01903665B361D211BF6700805FAD5D93591B39@mail.datarange.co.uk> Andrew, It sounds like a packet size issue. Windows browsers tend to set the "do not fragment" bit in packets, so the encapsulation overhead may push the router past the allowed packet size. You may need to allow some ping packets through to do MTU discovery, or change some registry variables - maybe others here could comment exactly what they are likely to be? try altering the MTU on the browser PC -if you set this to say 1400 bytes and it fixes the problem then you have confirmed it is probably packet size. More generally, i suggest you use a later code version - 12.07 or later seems much more stable than for previous versions. Stephen Hope C. Eng, Network Consultant, shope at energis-eis.co.uk, Energis Integration Services Ltd, WWW: http://www.energis-eis.co.uk Carrington Business Park, Carrington, Manchester , UK. M31 4ZU Tel: +44 (0)161 776 4190 Mob: +44 (0)7767 256 180 Fax: +44 (0)161 776 4189 > -----Original Message----- > From: Andrew.Fletcher at TAYWOOD.CO.UK > [mailto:Andrew.Fletcher at TAYWOOD.CO.UK] > Sent: Saturday, September 09, 2000 12:53 PM > To: VPN at SECURITYFOCUS.COM > Subject: vpn > > > Problem: > I have a point to point IPSec VPN configured on Cisco 1720 > Routers (IOS > Version 12.0(2a)T1). The VPN appears to be funcioning normally for all > protocols except for HTTP. Remote Users connecting to > Microsoft IIS/4.0 > (NT4.0 SP5) websites fail with a timeout, however connection to a Unix > Appache 1.3.1 works fine. On comparing protocol analyser > traces the only > apparent difference is the frame size negotiated in the TCP Header. On > IIS4, TCP sets mss to 1460. On Appache mss is set to 512. I > suspect the > problem maybe due to IP fragmentation. Any ideas would be greatly > appreciated. > > Additional info: > On the remote network we also have a Shiva remote access > server. When I > dial into this and connect through the VPN to IIS4 website, this works > fine. Again the network analyser shows the TCP mss set to 536 bytes > which appears to be acceptable. > > > Regards > > Andrew > > > Andrew Fletcher > IT Operations > Taylor Woodrow Construction Limited > 345 Ruislip Road, Southall, Middlesex, UB1 2QX. > > Tel: +44 (0)20.8575.4070 > Fax: +44 (0)870.160.3814 > > mailto:andrew.fletcher at taywood.co.uk > > > > ************************************************** > The information contained in this email is intended only for > the person or entity to whom it is addressed and may contain > confidential and/or privileged material. If you have received > this email in error please note that any review, > retransmission, copying, dissemination or other use of, or > taking of any action in reliance upon its contents is > prohibited. If you are not an intended recipient, Please > delete the material from any computer that may have it and > contact the Taylor Woodrow I.T Helpdesk on +44 (0)20 8575 > 4811, or send an email to helpdesk at taywood.co.uk. Thank you > for your co-operation. > > The contents of an attachment to this email may contain > software viruses which could damage your computer system. We > cannot accept liability for any damage which you sustain as a > result of software viruses. You should carry out your own > virus checks before opening any attachment. > ----------------------------------------------------------------------------------------------------------- This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Energis Integration Services. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. We have an anti-virus system installed on all our PC's and therefore any files leaving us via e-mail will have been checked for known viruses. Energis Integration Services accepts no responsibility once an e-mail and any attachments leave us. If you have received this email in error please notify Energis Integration Services Communications IT department on +44 (0) 1494 476222.. ----------------------------------------------------------------------------------------------------------- VPN is sponsored by SecurityFocus.COM From Kevin_Butters at NAI.COM Tue Sep 12 09:01:08 2000 From: Kevin_Butters at NAI.COM (Butters, Kevin) Date: Tue, 12 Sep 2000 06:01:08 -0700 Subject: Altsubject name question Message-ID: Ok. How about a follow-up question? I am using an IPsec client, and I want to add the Altsubject name attribute. Would it be expressed under the terms of an RFC 822 name? Kevin Butters -----Original Message----- From: Eric Vyncke [mailto:evyncke at CISCO.COM] Sent: Monday, September 11, 2000 1:37 PM To: VPN at SECURITYFOCUS.COM Subject: Re: Altsubject name question At 13:23 07/09/2000 -0700, Butters, Kevin wrote: One, what purpose does the Altsubject name server on a X.509 Certificate server? To put something which is not a plain distinguished name (which is the type of SubjectName). AltSubjectName can be anything including FQDN and IP addresses -eric Two, is Altsubject name = = Common Name? Kevin Butters VPN is sponsored by SecurityFocus.COM Eric Vyncke Senior Consulting Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke at cisco.com Mobile: +32-75-312.458 PGP Key available on request -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000912/c1394a2e/attachment.htm From matt at NEUROTRAIN.COM Tue Sep 12 10:39:12 2000 From: matt at NEUROTRAIN.COM (Matthew Harding) Date: Tue, 12 Sep 2000 10:39:12 -0400 Subject: Length of Triple DES algorithm Message-ID: <39BE4010.9C92F830@neurotrain.com> I have seen references to key length of triple DES ranging anywhere from 112 bits to 168, with stops of 128 bits in between. Is there a well established length for 3DES? Do some vendors implement 3DES differently, or is it just a naming convention? Are there any security implications between using 3DES with anything less than 168 bits? I had heard somewhere that the second transform with 3DES doesn't actually add anything to the overall security, hence it is only really 112 bits of protection. Any clarifications welcome! Thanks, Matthew -- Matthew Harding, Director NeuroTrain ATS Inc. Tel: 1-877-58-NEURO (613-824-6397) Fax: 613-841-2158 matt at neurotrain.com VPN is sponsored by SecurityFocus.COM From loloz at IFRANCE.COM Tue Sep 12 02:46:09 2000 From: loloz at IFRANCE.COM (Laurent Perruche) Date: Tue, 12 Sep 2000 08:46:09 +0200 Subject: ipsec+nat References: <4AB6F04F07BBD21191180008C70DD48F050C37DA@sp0002exch001u.es.lucent.com> Message-ID: <003f01c01c85$224306e0$9c00fe90@cisco.com> IPsec does work with NAT, if you don't use AH : NAT is incompatible with AH protocol, whether used in transport or tunnel mode. An IPsec VPN using AH protocol digitally signs the outbound packets, both data payload and headers, with a hash value appended to the packet. When using AH protocol, packet contents (the data payload) are not encrypted. Why this bothers NAT is the last part : a NAT device in between the IPsec endpoints will rewrite either the source or destination address with one of its own choosing. The VPN device at the receiving end will verify the integrity of the incoming packet by computing its own hash value, and will complain that the hash value appended to the received packet doesn't match. The VPN device at the receiving end doesn't know about the NAT in the middle, so it assumes that the data has been altered for nefarious purposes. IPsec using ESP in tunnel mode encapsulates the entire original packet (including headers) in a new IP packet. The new IP packet's source address is the outbound address of the sending VPN gateway, and its destination address is the inbound address of the VPN device at the receiving end. When using ESP protocol with authentication, the packet contents, but not the new headers, are signed with a hash value appended to the packet. This mode (tunnel mode ESP with authentication) is compatible with NAT, because integrity checks are performed over the combination of the ? original header plus original payload ?, which is unchanged by a NAT device. Transport mode ESP with authentication is also compatible with NAT, but is not often used by itself. Since the hash is computed only over the original payload, original headers may be rewriten. ----- Message d'origine ----- De : "Martin, Jose Carlos (Jose)" ? : Envoy? : jeudi 7 septembre 2000 18:51 Objet : ipsec+nat Hello all, I would like to know if NAT and IPSEC are compatible when using ESP (both tunnel and transport mode). Thanks in advance, Jos? Carlos VPN is sponsored by SecurityFocus.COM ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs ? gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif VPN is sponsored by SecurityFocus.COM From mhw at WITTSEND.COM Tue Sep 12 13:33:48 2000 From: mhw at WITTSEND.COM (Michael H. Warfield) Date: Tue, 12 Sep 2000 13:33:48 -0400 Subject: Length of Triple DES algorithm In-Reply-To: <39BE4010.9C92F830@neurotrain.com>; from matt@NEUROTRAIN.COM on Tue, Sep 12, 2000 at 10:39:12AM -0400 References: <39BE4010.9C92F830@neurotrain.com> Message-ID: <20000912133348.A8227@alcove.wittsend.com> On Tue, Sep 12, 2000 at 10:39:12AM -0400, Matthew Harding wrote: > I have seen references to key length of triple DES ranging anywhere from > 112 bits to 168, with stops of 128 bits in between. > Is there a well established length for 3DES? Do some vendors implement > 3DES differently, or is it just a naming convention? Are there any > security implications between using 3DES with anything less than 168 > bits? I had heard somewhere that the second transform with 3DES doesn't > actually add anything to the overall security, hence it is only really > 112 bits of protection. The key is the key... 3DES is three passes through the DES algorithm with each key (K1, K2, K3) being 56 bits. Convention is to use DES in encrypt mode on the first pass, decrypt mode on the second, and encrypt mode on the third (EDE mode). So what this means is that, to encrypt with 3DES, you encrypt with K1, then decrypt with K2, then encrypt with K3. Decryption is just the reverse. You decrypt with K3, then encrypt with K2, then decrypt with K1. As I said, the key is the key... If K1, K2, and K3 are all different, you have 168 bit 3DES. If K1 == K3, you have 112 bit 3DES. You merely encrypt with K1 twice. This prevents "meet in the middle" attacks which can be employed against the encryption if you only passed through DES twice. If K1 == K2 == K3, this is DES compatibility mode (the first encrypt is canceled by the decrypt in the second pass) and allows 3DES engines to process single DES traffic by merely setting the three 56 bit keys identical. Actually, any time either K1 == K2 or K2 == K3, you have only 56 bits of encryption strength and the real key is the odd key, since the matching keys cancel (unlike the K1 == K3 case where you end up encrypting with the same key twice). As far as the second transform not adding to the security, that is absolutely not true. Reference to Bruce Schneier's "Applied Cryptography". > Any clarifications welcome! > Thanks, > Matthew > -- > Matthew Harding, Director > NeuroTrain ATS Inc. > Tel: 1-877-58-NEURO (613-824-6397) > Fax: 613-841-2158 > matt at neurotrain.com Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! VPN is sponsored by SecurityFocus.COM From tmmather at SYMANTEC.COM Tue Sep 12 14:32:56 2000 From: tmmather at SYMANTEC.COM (Tim Mather) Date: Tue, 12 Sep 2000 11:32:56 -0700 Subject: Length of Triple DES algorithm Message-ID: Triple DES can be implemented in at least two different ways, that I am aware of. Key #1 = key #3 with key #2 being different = 112 bits (2 * 56 bits). "True" triple DES is keys #1, #2, and #3 all being different from each other = 168 bits (3 * 56 bits). How vendors get to different lengths is interesting to me. Thanks. Tim Matthew Harding @SECURITYFOCUS.COM> on 09/12/2000 07:39:12 AM Please respond to Matthew Harding Sent by: VPN Mailing List From ryan at SECURITYFOCUS.COM Tue Sep 12 15:21:53 2000 From: ryan at SECURITYFOCUS.COM (Ryan Russell) Date: Tue, 12 Sep 2000 12:21:53 -0700 Subject: Length of Triple DES algorithm In-Reply-To: Message-ID: You can do 128 by using the 168 variant and setting 40 of the bits to 0 (or any published value.) Effective length in terms of brute force is then 128, since 40 of the bits are known to the cracker. Ryan On Tue, 12 Sep 2000, Tim Mather wrote: > Triple DES can be implemented in at least two different ways, that I > am aware of. Key #1 = key #3 with key #2 being different = 112 bits (2 * > 56 bits). "True" triple DES is keys #1, #2, and #3 all being different > from each other = 168 bits (3 * 56 bits). How vendors get to different > lengths is interesting to me. > Thanks. > > Tim > > > > > > Matthew Harding @SECURITYFOCUS.COM> on 09/12/2000 > 07:39:12 AM > > Please respond to Matthew Harding > > Sent by: VPN Mailing List > > > > To: VPN at SECURITYFOCUS.COM > cc: > Subject: Length of Triple DES algorithm > > > I have seen references to key length of triple DES ranging anywhere from > 112 bits to 168, with stops of 128 bits in between. > > Is there a well established length for 3DES? Do some vendors implement > 3DES differently, or is it just a naming convention? Are there any > security implications between using 3DES with anything less than 168 > bits? I had heard somewhere that the second transform with 3DES doesn't > actually add anything to the overall security, hence it is only really > 112 bits of protection. > > Any clarifications welcome! > > Thanks, > Matthew > > -- > Matthew Harding, Director > NeuroTrain ATS Inc. > Tel: 1-877-58-NEURO (613-824-6397) > Fax: 613-841-2158 > matt at neurotrain.com > > VPN is sponsored by SecurityFocus.COM > > VPN is sponsored by SecurityFocus.COM > VPN is sponsored by SecurityFocus.COM From humphrie at WFUBMC.EDU Tue Sep 12 15:19:49 2000 From: humphrie at WFUBMC.EDU (Tait Humphries) Date: Tue, 12 Sep 2000 15:19:49 -0400 Subject: Checkpoint & Contivity Message-ID: <39BE81D4.6FB6B6DE@wfubmc.edu> I have an affiliate that needs to run IPSec clients behind a Checkpoint firewall to connect to our VPN (Nortel Contivity). They are using NAT so obviously there are issues. My contact says that he doesn't have enough legal IP addresses to give them to the six to eight people that will need to run the VPN client. I'm not familiar with setting up branch connections (I would like to avoid this if possible). Does anyone know of a way to avoid branch connections in this scenario & if not does anyone out there have any experience setting up this type of connection. I only have lab experience with Nortel to Nortel devices. Thanks, Tait -------------- next part -------------- A non-text attachment was scrubbed... Name: humphrie.vcf Type: text/x-vcard Size: 351 bytes Desc: Card for Tait Humphries Url : http://lists.shmoo.com/pipermail/vpn/attachments/20000912/2dc05e7b/attachment.vcf From sandy at STORM.CA Tue Sep 12 16:10:18 2000 From: sandy at STORM.CA (Sandy Harris) Date: Tue, 12 Sep 2000 16:10:18 -0400 Subject: Length of Triple DES algorithm References: <39BE4010.9C92F830@neurotrain.com> Message-ID: <39BE8DAA.AFF933A@storm.ca> Matthew Harding wrote: > > I have seen references to key length of triple DES ranging anywhere from > 112 bits to 168, with stops of 128 bits in between. You can do it with two keys, 2*56 = 112 bits, or with three, 3*56 = 168. The IPSEC standards require the three-key variant. > Is there a well established length for 3DES? Do some vendors implement > 3DES differently, or is it just a naming convention? Are there any > security implications between using 3DES with anything less than 168 > bits? I had heard somewhere that the second transform with 3DES doesn't > actually add anything to the overall security, hence it is only really > 112 bits of protection. There's a simple meet-in-the middle attack that requires "only" 2 ^112 encryptions, but it needs some absurd amount of memory. More sophisticated variants reduce both the number of encryptions and the memory used, but not far enough to make them practical attacks. For more detail: http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/glossary.html#3DES and follow the links to other glossary entries. VPN is sponsored by SecurityFocus.COM From evyncke at CISCO.COM Tue Sep 12 17:03:05 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Tue, 12 Sep 2000 23:03:05 +0200 Subject: Length of Triple DES algorithm In-Reply-To: <39BE4010.9C92F830@neurotrain.com> Message-ID: <4.2.0.58.20000912225903.00a78d30@brussels.cisco.com> Matthew, Other people have already poured their pound of knowledge, but, may I add my own one ? IPSec ESP 3DES requires to use 3 different keys, hence key length is 3*56bits = 168 bits. This means that all IPSec ESP 3DES are using a key length of 168 bits. There is also IPSec ESP DES with 56 bits. But, there is neither RFC not IETF drafts for a variant of 128 bits or 112 bits for IPSec ESP But there is an attack requiring a huge amount of memory (see Bruce Schneir's book -- something like 100,000 TB) that can break the 3DES key in 2**112 rounds. Hence, with this huge memory assumption, the actual key strength is 112 bits. Hence the confusion Regards -eric At 10:39 12/09/2000 -0400, Matthew Harding wrote: >I have seen references to key length of triple DES ranging anywhere from >112 bits to 168, with stops of 128 bits in between. > >Is there a well established length for 3DES? Do some vendors implement >3DES differently, or is it just a naming convention? Are there any >security implications between using 3DES with anything less than 168 >bits? I had heard somewhere that the second transform with 3DES doesn't >actually add anything to the overall security, hence it is only really >112 bits of protection. > >Any clarifications welcome! > >Thanks, >Matthew > >-- >Matthew Harding, Director >NeuroTrain ATS Inc. >Tel: 1-877-58-NEURO (613-824-6397) >Fax: 613-841-2158 >matt at neurotrain.com > >VPN is sponsored by SecurityFocus.COM Eric Vyncke Senior Consulting Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke at cisco.com Mobile: +32-75-312.458 PGP Key available on request VPN is sponsored by SecurityFocus.COM From Sebastien_Talha at NAI.COM Wed Sep 13 14:15:36 2000 From: Sebastien_Talha at NAI.COM (Talha, Sebastien) Date: Wed, 13 Sep 2000 20:15:36 +0200 Subject: Length of Triple DES algorithm Message-ID: <8FE0C8D363A9D111943D00A0C99B6019AAD833@par-exchange1.nai.com> In fact 3DES is just a triple XDES, that can use E-E-E or E-D-E (E=encryption; D=decryption), and different key lengths like real DES 56 bits keys or 64 bits keys with 8 parity bits, that's why you have sometimes 3DEs at 192 bits. When you are doing triple DES with key1=key3, the entropy is in fact 112 bits (but is like trying to crack an effective 129 bits keys regarding the amount of data you can put in to try to crack that key etc...). When key1 is different than key3 (real triple DES), you have an effective entropy up to 168 bits. Try to have more informations by downloading the RSAfaq: all encryption information is in there, regarding all subjects: it's a really good start and after still usuable. Hope this helps. Seb. -----Original Message----- From: Matthew Harding [mailto:matt at NEUROTRAIN.COM] Sent: Tuesday, September 12, 2000 3:39 PM To: VPN at SECURITYFOCUS.COM Subject: Length of Triple DES algorithm I have seen references to key length of triple DES ranging anywhere from 112 bits to 168, with stops of 128 bits in between. Is there a well established length for 3DES? Do some vendors implement 3DES differently, or is it just a naming convention? Are there any security implications between using 3DES with anything less than 168 bits? I had heard somewhere that the second transform with 3DES doesn't actually add anything to the overall security, hence it is only really 112 bits of protection. Any clarifications welcome! Thanks, Matthew -- Matthew Harding, Director NeuroTrain ATS Inc. Tel: 1-877-58-NEURO (613-824-6397) Fax: 613-841-2158 matt at neurotrain.com VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From Joakim.Aronius at CA.COM Wed Sep 13 07:25:26 2000 From: Joakim.Aronius at CA.COM (Aronius, Joakim) Date: Wed, 13 Sep 2000 12:25:26 +0100 Subject: Length of Triple DES algorithm Message-ID: <3169049FA29BD311B626009027DE38BD032CE12F@ukslms03.cai.com> Small clarification: And the reason why the keylengths are 56, 112 and 168 instead of 64, 128 and 192 (which they are) is because 8 bits of each 64 bit block contains a checksum. This means that a 64 bit key has (at most) an entropy of 56 bits. Any reference to 64, 128 or 192 bit DES is the same as 56, 112 or 168 bits, respectively. Joakim Aronius -----Original Message----- From: Michael H. Warfield [mailto:mhw at WITTSEND.COM] Sent: den 12 september 2000 19:34 To: VPN at SECURITYFOCUS.COM Subject: Re: Length of Triple DES algorithm On Tue, Sep 12, 2000 at 10:39:12AM -0400, Matthew Harding wrote: > I have seen references to key length of triple DES ranging anywhere from > 112 bits to 168, with stops of 128 bits in between. > Is there a well established length for 3DES? Do some vendors implement > 3DES differently, or is it just a naming convention? Are there any > security implications between using 3DES with anything less than 168 > bits? I had heard somewhere that the second transform with 3DES doesn't > actually add anything to the overall security, hence it is only really > 112 bits of protection. The key is the key... 3DES is three passes through the DES algorithm with each key (K1, K2, K3) being 56 bits. Convention is to use DES in encrypt mode on the first pass, decrypt mode on the second, and encrypt mode on the third (EDE mode). So what this means is that, to encrypt with 3DES, you encrypt with K1, then decrypt with K2, then encrypt with K3. Decryption is just the reverse. You decrypt with K3, then encrypt with K2, then decrypt with K1. As I said, the key is the key... If K1, K2, and K3 are all different, you have 168 bit 3DES. If K1 == K3, you have 112 bit 3DES. You merely encrypt with K1 twice. This prevents "meet in the middle" attacks which can be employed against the encryption if you only passed through DES twice. If K1 == K2 == K3, this is DES compatibility mode (the first encrypt is canceled by the decrypt in the second pass) and allows 3DES engines to process single DES traffic by merely setting the three 56 bit keys identical. Actually, any time either K1 == K2 or K2 == K3, you have only 56 bits of encryption strength and the real key is the odd key, since the matching keys cancel (unlike the K1 == K3 case where you end up encrypting with the same key twice). As far as the second transform not adding to the security, that is absolutely not true. Reference to Bruce Schneier's "Applied Cryptography". > Any clarifications welcome! > Thanks, > Matthew > -- > Matthew Harding, Director > NeuroTrain ATS Inc. > Tel: 1-877-58-NEURO (613-824-6397) > Fax: 613-841-2158 > matt at neurotrain.com Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! VPN is sponsored by SecurityFocus.COM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000913/ecaad650/attachment.htm From jan at NIL.SI Wed Sep 13 14:58:12 2000 From: jan at NIL.SI (Jan Bervar) Date: Wed, 13 Sep 2000 20:58:12 +0200 Subject: Length of Triple DES algorithm Message-ID: On 12.09.2000 23:03:05 Eric Vyncke wrote: > But there is an attack requiring a huge amount of memory (see Bruce > Schneir's > book -- something like 100,000 TB) that can break the 3DES key in 2**112 > rounds. Hence, with this huge memory assumption, the actual key strength > is 112 bits. Hence the confusion Hi Eric and all, what's the current story about French crypto import laws? I've heard that they limit domestic use to 128-bits (true?). Does that make 3DES ok (the lower limit being 2^112 in complexity for 3 different keys), or not ok (as it is "officially" 168-bit)? Cheers, Jan Jan Bervar Specialist za podatkovne komunikacije, CCIE #2527 Consulting Engineer NIL Data Communications, Einspielerjeva 6, 1000 Ljubljana, Slovenia Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si VPN is sponsored by SecurityFocus.COM From bekoin at GLOBEACCESS.NET Thu Sep 14 04:16:20 2000 From: bekoin at GLOBEACCESS.NET (IMPAP) Date: Thu, 14 Sep 2000 08:16:20 -0000 Subject: IPSec tunnel References: Message-ID: <001201c01e24$1298beb0$0100000a@support.net> I implement IPSec with 2 W2K Advanced Server. IPSec monitor shows that the tunnel is created. What i want to know if it exist some tools to see if encryption is done and also to see the trafic thanks VPN is sponsored by SecurityFocus.COM From maikel at WORLDONLINE.NL Thu Sep 14 05:14:33 2000 From: maikel at WORLDONLINE.NL (Maikel Verheijen) Date: Thu, 14 Sep 2000 11:14:33 +0200 Subject: IPSEC between FreeBSD 4.1(KAME + Racoon) and Win2k Message-ID: <20000914111433.Q83759@intramail.worldonline.nl> Hi all Did anyone got IPSEC between FreeBSD 4.1 with racoon and KAME working against Windows2000 ipsec? 2 FreeBSD machines work very nicely together with racoon and static keying, however I would like win2k to be able to communicate over IPSEC as well :) TIA, Maikel Verheijen. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 248 bytes Desc: not available Url : http://lists.shmoo.com/pipermail/vpn/attachments/20000914/8d097677/attachment.pgp From evyncke at CISCO.COM Thu Sep 14 09:32:49 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Thu, 14 Sep 2000 15:32:49 +0200 Subject: Length of Triple DES algorithm In-Reply-To: from "Jan Bervar" at Sep 13, 2000 08:58:12 PM Message-ID: <200009141332.PAA02711@brussels.cisco.com> Hello Jan, I'll let a FRench lawyer to give the definitive answer, but, the trick is that any alg <=128 bits is automatically granted domestic usage upon the deposit of a lot of paper while the rest requires more paperwork and meetings. But, for insistance, Cisco 3DES has been approved by the French organizationin charge of granted license. Just my 0.01 EUR -eric > > On 12.09.2000 23:03:05 Eric Vyncke wrote: > > But there is an attack requiring a huge amount of memory (see Bruce > > Schneir's > > book -- something like 100,000 TB) that can break the 3DES key in 2**112 > > rounds. Hence, with this huge memory assumption, the actual key strength > > is 112 bits. Hence the confusion > > Hi Eric and all, > > > what's the current story about French crypto import laws? I've heard that > they limit domestic use to 128-bits (true?). Does that make 3DES ok > (the lower limit being 2^112 in complexity for 3 different keys), or not > ok (as it is "officially" 168-bit)? > > Cheers, > Jan > > Jan Bervar > Specialist za podatkovne komunikacije, CCIE #2527 > Consulting Engineer > NIL Data Communications, Einspielerjeva 6, 1000 Ljubljana, Slovenia > Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si > > VPN is sponsored by SecurityFocus.COM > VPN is sponsored by SecurityFocus.COM From ramesh at SCR.SIEMENS.COM Thu Sep 14 10:50:47 2000 From: ramesh at SCR.SIEMENS.COM (Viswanathan, Ramesh (CNA)) Date: Thu, 14 Sep 2000 10:50:47 -0400 Subject: Nortel extranet client for Win2K Message-ID: <1F140156A8C6D211A7B500A0C9068FBB096017@exchange.scr.siemens.com> Nortel has just released the v2.62 Extranet Client which supports the Win2K OS. You can download it from their support web site. Ramesh VPN is sponsored by SecurityFocus.COM From marcvh at AVENTAIL.COM Thu Sep 14 16:17:35 2000 From: marcvh at AVENTAIL.COM (Marc VanHeyningen) Date: Thu, 14 Sep 2000 13:17:35 -0700 Subject: Length of Triple DES algorithm In-Reply-To: Your message of "Thu, 14 Sep 2000 15:32:49 +0200." <200009141332.PAA02711@brussels.cisco.com> Message-ID: <10465.968962655@aventail.com> > Hello Jan, > > > what's the current story about French crypto import laws? I've heard that > > they limit domestic use to 128-bits (true?). Does that make 3DES ok > > (the lower limit being 2^112 in complexity for 3 different keys), or not > > ok (as it is "officially" 168-bit)? > I'll let a FRench lawyer to give the definitive answer, but, the trick > is that any alg <=128 bits is automatically granted domestic usage > upon the deposit of a lot of paper while the rest requires more > paperwork and meetings. But, for insistance, Cisco 3DES has been > approved by the French organizationin charge of granted license. That's consistent with my understanding; I do not believe they accept "but triple-DES is really only 112 bits, not 168" as an argument. One wonders where this 128 bit distinction comes from. -- Marc VanHeyningen marcvh at aventail.com Internet Security Architect Aventail http://www.aventail.com/ VPN is sponsored by SecurityFocus.COM From paulw at CAIS.COM Thu Sep 14 15:40:01 2000 From: paulw at CAIS.COM (Paul Anderson) Date: Thu, 14 Sep 2000 15:40:01 -0400 Subject: FW: Recommended NIC cards Message-ID: <000301c01e83$9309b590$2263d93f@server1> Regards, Paul Anderson -----Original Message----- From: Tina Bird [mailto:tbird at precision-guesswork.com] Sent: Thursday, September 14, 2000 1:30 PM To: Paul Anderson Subject: Re: Recommended NIC cards Paul -- Please post this to the VPN mailing list. For the most part, as long as you're doing Ethernet, you shouldn't have any brand dependency. I know that not all tokenring and ATM cards have drivers on all possible operating systems that support VPN architecture. the list is vpn at securityfocus.com On Thu, 14 Sep 2000, Paul Anderson wrote: > Date: Thu, 14 Sep 2000 08:29:46 -0400 > From: Paul Anderson > To: tbird at precision-guesswork.com > Subject: Recommended NIC cards > > I wish to know what is the recommended NIC card to use as second adapter > card for VPN implementation. None of the documents on your site go into the > hardware end of installation. Netopia routers also are not discussed. > Please respond via email. > > Respectfully, > > Paul W. Anderson > Systems Manager > Manhattan Total Health > > VPN: http://kubarb.phsx.ukans.edu/~tbird/vpn.html life: http://kubarb.phsx.ukans.edu/~tbird work: http://www.counterpane.com VPN is sponsored by SecurityFocus.COM From gbincik at DMTISPATIAL.COM Thu Sep 14 15:33:13 2000 From: gbincik at DMTISPATIAL.COM (Gabriel Bincik) Date: Thu, 14 Sep 2000 15:33:13 -0400 Subject: Nortel extranet client for Win2K Message-ID: <9DABA45C19A5D31181AD00508B4AB1323C44@DMTI_MESSENGER> While the Nortel v2.62 Extranet Client which supports the Win2K OS is online at their website, you must have a service agreement with them to obtain the username and password to access the download. Gabe Bincik DMTI Spatial Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000914/668bfcfe/attachment.htm From Michael.Medwid at ARIBA.COM Thu Sep 14 16:52:51 2000 From: Michael.Medwid at ARIBA.COM (Michael Medwid) Date: Thu, 14 Sep 2000 13:52:51 -0700 Subject: Any word on a Win2K client for Cisco CVPN30XX? Message-ID: <271DE2625FD4D311949B009027F43B9F02E97963@us-mtvmail2.ariba.com> I have yet to year of a Cisco IPsec client for Win2K. And Cisco offers no instructions in how to set up Win2K's native IPsec support to be compatible with the CVPN 30XX (Altiga.) Anyone on the list have their Win2K talking IPsec to a CVPN 30XX/Altiga? VPN is sponsored by SecurityFocus.COM From josef.pojsl at SKYNET.CZ Fri Sep 15 04:34:03 2000 From: josef.pojsl at SKYNET.CZ (Josef Pojsl) Date: Fri, 15 Sep 2000 10:34:03 +0200 Subject: IPSEC between FreeBSD 4.1(KAME + Racoon) and Win2k In-Reply-To: <20000914111433.Q83759@intramail.worldonline.nl>; from maikel@WORLDONLINE.NL on Thu, Sep 14, 2000 at 11:14:33AM +0200 References: <20000914111433.Q83759@intramail.worldonline.nl> Message-ID: <20000915103403.F80763@regent.in.skynet.cz> Hi Maikel, AFAIK, this is not going to work. KAME/racoon uses tunnel mode IPsec while Win2K uses IPsec in transport mode and L2TP for tunneling private address space inside it. See also the following URL (as an example): http://www.microsoft.com/windows2000/library/resources/reskit/samplechapters/inbe/inbe_vpn_njvv.asp Regards, Josef On Thu, Sep 14, 2000 at 11:14:33AM +0200, Maikel Verheijen wrote: > Hi all > > Did anyone got IPSEC between FreeBSD 4.1 with racoon and KAME working > against Windows2000 ipsec? > > 2 FreeBSD machines work very nicely together with racoon and static > keying, however I would like win2k to be able to communicate over IPSEC as > well :) > > TIA, > > Maikel Verheijen. VPN is sponsored by SecurityFocus.COM From MuniX-1 at PACBELL.NET Fri Sep 15 02:03:57 2000 From: MuniX-1 at PACBELL.NET (Jose Muniz) Date: Thu, 14 Sep 2000 23:03:57 -0700 Subject: HA IPSec session failover..Checkpoint References: <001201c01e24$1298beb0$0100000a@support.net> Message-ID: <39C1BBCD.1C93D921@pacbell.net> Hello Guys; I need to set up a very scalable VPN using Checkpoint FW1. Has anyone set up a VPN in HA mode, that has the capabilities of IPSec session fail over without having to re-key? I have tested the Nokia stuff with the VRRP monitor circuit and did not work. THere is also the Checkpoint HA and the Stonebeat stuff. Why a singke product with 3 HA solutions? I was not able to get a straight answer from neither Nokia or Checkpoint. If someone has anything to say about it it will be gracefully appreciated with the ZEN of VPN ! Jose Muniz VPN is sponsored by SecurityFocus.COM From Markus.Moullion at DE.BOSCH.COM Fri Sep 15 03:31:12 2000 From: Markus.Moullion at DE.BOSCH.COM (Moullion Markus (QI/LSD1) *) Date: Fri, 15 Sep 2000 09:31:12 +0200 Subject: AW: Any word on a Win2K client for Cisco CVPN30XX? Message-ID: Hello Michael, I have set up a Cisco VPN Concentrator 3005 (formerly Altiga) to work with W2K clients and it works quit fine. The most important fact is, that W2K Prof. does not support pure IPSec for remote access via VPN, it uses L2TP/IPSec. So if you would like to use your W2K client without additional IPSec client software, you have to use L2TP/IPSec. L2TP/IPSec requires certificates for computer authentication, so I installed a W2K certification authority (CA) to generate the necessary certificates for the clients and the VPN concentrator. The documentation shipped with the concentrator does not help much. Ask Cisco for more detailed information (they have it). Regards, Markus -----Urspr?ngliche Nachricht----- Von: Michael Medwid [mailto:Michael.Medwid at ARIBA.COM] Gesendet: Donnerstag, 14. September 2000 22:53 An: VPN at SECURITYFOCUS.COM Betreff: Any word on a Win2K client for Cisco CVPN30XX? I have yet to year of a Cisco IPsec client for Win2K. And Cisco offers no instructions in how to set up Win2K's native IPsec support to be compatible with the CVPN 30XX (Altiga.) Anyone on the list have their Win2K talking IPsec to a CVPN 30XX/Altiga? VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From evyncke at CISCO.COM Fri Sep 15 03:52:33 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Fri, 15 Sep 2000 09:52:33 +0200 Subject: Length of Triple DES algorithm In-Reply-To: <10465.968962655@aventail.com> from "Marc VanHeyningen" at Sep 14, 2000 01:17:35 PM Message-ID: <200009150752.JAA07089@brussels.cisco.com> > > That's consistent with my understanding; I do not believe they accept > "but triple-DES is really only 112 bits, not 168" as an argument. One > wonders where this 128 bit distinction comes from. > >From SSL browsers having 128 bits RC4 ;) No wonder that a political guy cannot make a difference between 168-bits 3DES and 128-bits RC4 :) -eric > -- > Marc VanHeyningen marcvh at aventail.com > Internet Security Architect > Aventail http://www.aventail.com/ > > > VPN is sponsored by SecurityFocus.COM From gjensen1 at HOME.COM Fri Sep 15 09:01:08 2000 From: gjensen1 at HOME.COM (Gary) Date: Fri, 15 Sep 2000 08:01:08 -0500 Subject: Fw: Mode-Config question Message-ID: <007101c01f15$03b7df10$01000001@gregjlt> Does anybody know the difference between the various forms of Mode-Config that companies like Cisco, CheckPoint, PGP, Altiga and others are providing? I've been told that there are several companies providing Mode-Config services, but that there are not any compatabilities between the various vendors. Can anybody shed some light on this? What vendors provide this, and does anybody know if any of the Mode-Config solutions work with one another (client to gateway compatability). -Gary Jensen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000915/ea76bab0/attachment.htm From franci.jereb at MIBO.SI Mon Sep 18 09:15:32 2000 From: franci.jereb at MIBO.SI (Franci Jereb) Date: Mon, 18 Sep 2000 15:15:32 +0200 Subject: Contivity & Entrust Message-ID: <39C63194.31674.D8A235@localhost> Hello, I would like to know if anybody was configuring Contivity 1500 with Extranet Access Client (software) to authenticate over Entrust Digital Certificate. Software version of Contivity is 2.50. As far as i know I should give to authenticate the request to the CA. The only one in our country is our competition, so I can't send it to authenticate to them. Can anybody help me out of this mess, 'cause in 2 weeks is in our country big fair of modern electronics, so it would be nice if it would be working. Regards, Frenk VPN is sponsored by SecurityFocus.COM From Joel.Snyder at OPUS1.COM Mon Sep 18 10:32:35 2000 From: Joel.Snyder at OPUS1.COM (Joel M Snyder) Date: Mon, 18 Sep 2000 07:32:35 -0700 Subject: VPN Vendors: Network World is reviewing Enterprise products Message-ID: <01JUB6ZB057WB8JKIP@Opus1.COM> Network World is running a review of enterprise VPN products with emphasis on high availability features. If you sell VPN products that fit in the enterprise, send mail to me for a copy of the invite or read it online at: http://www.opus1.com/www/jms/vpn3-invite.html If you're a customer of a vendor who doesn't get reviewed often because their PR people never seem to get these, you may want to forward this to your sales droid. Sorry for the interruption; we now return you to our regularly scheduled programming. jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX) jms at Opus1.COM http://www.opus1.com/jms Opus One VPN is sponsored by SecurityFocus.COM From guy.raymakers at EDS.COM Sat Sep 16 10:51:04 2000 From: guy.raymakers at EDS.COM (Raymakers, Guy) Date: Sat, 16 Sep 2000 15:51:04 +0100 Subject: HA IPSec session failover..Checkpoint Message-ID: Hi Jose, If you have to use FW1, this mail is maybe not interesting for you ..... I don't know about FW-1, but the Nokia Cryptocluster's are doing failover without the need to re-key IPSec sessions. Guy -----Original Message----- From: Jose Muniz [mailto:MuniX-1 at Pacbell.net] Sent: vrijdag 15 september 2000 08:04 To: VPN at SECURITYFOCUS.COM Subject: HA IPSec session failover..Checkpoint Hello Guys; I need to set up a very scalable VPN using Checkpoint FW1. Has anyone set up a VPN in HA mode, that has the capabilities of IPSec session fail over without having to re-key? I have tested the Nokia stuff with the VRRP monitor circuit and did not work. THere is also the Checkpoint HA and the Stonebeat stuff. Why a singke product with 3 HA solutions? I was not able to get a straight answer from neither Nokia or Checkpoint. If someone has anything to say about it it will be gracefully appreciated with the ZEN of VPN ! Jose Muniz VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From cdschuler at HOME.COM Mon Sep 18 16:41:50 2000 From: cdschuler at HOME.COM (Cameron Schuler) Date: Mon, 18 Sep 2000 14:41:50 -0600 Subject: Transparent NAT Message-ID: <39C629AE.14141.1A90ABA@localhost> Today I met with a VPN appliance manufacturer. I was told that there is a significant problem with NAT when there is a router between the VPN appliance and the end user. From what I'm told the problem lies with the fact that both the VPN and the router are conducting NAT between each other and therefore there needs to be transparent NAT to alleviate this. They don't have the software patch yet. Is there a patch for this on the software side rather than purchasing their additional hardware to fix it? Thank you, Cameron Schuler VPN is sponsored by SecurityFocus.COM From dnewman at NETWORKTEST.COM Mon Sep 18 18:04:20 2000 From: dnewman at NETWORKTEST.COM (David Newman) Date: Mon, 18 Sep 2000 18:04:20 -0400 Subject: vpn test results Message-ID: CommWeb recently published results of an evaluation of 12 IPSec gateways. The article includes evaluations of device security, performance, and management. Results are available here: http://www.commweb.com/article/COM20000912S0009 Regards, David Newman Network Test VPN is sponsored by SecurityFocus.COM From Daryl_Fallin at NAI.COM Tue Sep 19 10:15:37 2000 From: Daryl_Fallin at NAI.COM (Fallin, Daryl) Date: Tue, 19 Sep 2000 07:15:37 -0700 Subject: PPTP?? Any change Message-ID: Has Microsoft ever addressed the security issues that are listed on Tina's VPN website? Thanks Daryl VPN is sponsored by SecurityFocus.COM From rgm at ICSA.NET Mon Sep 18 18:59:58 2000 From: rgm at ICSA.NET (Robert Moskowitz) Date: Mon, 18 Sep 2000 18:59:58 -0400 Subject: Altsubject name question In-Reply-To: Message-ID: <4.3.2.7.2.20000918185747.00dbac30@homebase.htt-consult.com> At 06:01 AM 9/12/2000 -0700, Butters, Kevin wrote: >Ok. How about a follow-up question? I am using an IPsec client, and I want >to add the Altsubject name attribute. Would it be expressed under the >terms of an RFC 822 name? Check out RFC 2459 and search on altSubjectName this certificate extention can be any number of different 'types' this includes: DN (X.500 naming) FQDN (DNS name) IP4address (1.2.3.4) rfc822Name (me at mydomain.com) >-----Original Message----- >From: Eric Vyncke [mailto:evyncke at CISCO.COM] >Sent: Monday, September 11, 2000 1:37 PM >To: VPN at SECURITYFOCUS.COM >Subject: Re: Altsubject name question > >At 13:23 07/09/2000 -0700, Butters, Kevin wrote: >>One, what purpose does the Altsubject name server on a X.509 Certificate >>server? >To put something which is not a plain distinguished name (which is >the type of SubjectName). AltSubjectName can be anything including >FQDN and IP addresses Robert Moskowitz ICSA.net (248) 968-9809 Fax: (248) 968-2824 rgm at icsa.net There's no limit to what can be accomplished if it doesn't matter who gets the credit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000918/6280d790/attachment.htm From rudolph at MEITCA.COM Tue Sep 19 08:42:19 2000 From: rudolph at MEITCA.COM (David Rudolph) Date: Tue, 19 Sep 2000 05:42:19 -0700 Subject: VPN disables access to local corporate LAN Message-ID: <39C75F2B286.6202RUDOLPH@dpw.meitca.com> I'm new to VPN, and I'm looking for some help in getting things set up. The basic problem is that, as soon as I connect to the VPN, I lose access to my local corporate LAN. Here the details. I am working at Company A, and am attached physically to their corporate LAN. I'm trying to connect to Company B using VPN. As soon as I dial, and get connected to Company B, I no longer seem to be able to access anything on Company A's LAN. For example, my mail client can no longer find the mail server, and telnet can no longer find any of the machines on the local LAN. I'm running Windows NT 4.0, service pack 6. Is there any way around this? ---------------------------------------------------------------------------- David Rudolph | phone: (781) 466-8370 Mitsubishi Electric Research Labs | email: rudolph at merl.com ---------------------------------------------------------------------------- VPN is sponsored by SecurityFocus.COM From lthompson at IRE.COM Tue Sep 19 14:52:32 2000 From: lthompson at IRE.COM (Larry Thompson) Date: Tue, 19 Sep 2000 14:52:32 -0400 Subject: FW: VPN disables access to local corporate LAN Message-ID: Uncheck the box in the dial settings to use the dial connection as the default gateway. -----Original Message----- From: David Rudolph [mailto:rudolph at MEITCA.COM] Sent: Tuesday, September 19, 2000 8:42 AM To: VPN at SECURITYFOCUS.COM Subject: VPN disables access to local corporate LAN I'm new to VPN, and I'm looking for some help in getting things set up. The basic problem is that, as soon as I connect to the VPN, I lose access to my local corporate LAN. Here the details. I am working at Company A, and am attached physically to their corporate LAN. I'm trying to connect to Company B using VPN. As soon as I dial, and get connected to Company B, I no longer seem to be able to access anything on Company A's LAN. For example, my mail client can no longer find the mail server, and telnet can no longer find any of the machines on the local LAN. I'm running Windows NT 4.0, service pack 6. Is there any way around this? ---------------------------------------------------------------------------- David Rudolph | phone: (781) 466-8370 Mitsubishi Electric Research Labs | email: rudolph at merl.com ---------------------------------------------------------------------------- VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From dgillett at NIKU.COM Tue Sep 19 15:19:56 2000 From: dgillett at NIKU.COM (David Gillett) Date: Tue, 19 Sep 2000 12:19:56 -0700 Subject: VPN disables access to local corporate LAN In-Reply-To: <39C75F2B286.6202RUDOLPH@dpw.meitca.com> Message-ID: <003501c0226e$9908c690$f30410ac@niku.com> Consider, for a moment, if you *could* simultaneously talk to both networks. There would be a possibility, depending on configuration, that your machine could even *route* traffic between them. Your machine is trusted on Company A's network, and it's quite likely that when you establish a VPN connection to Company B's network, you become trusted there, too. But neither Company A nor Company B should be comfortable with the idea of trusting the other's entire LAN on that basis! So the behaviour you've encountered is quite normal; during the time that you are connected over the VPN, your machine is a trusted member of Company B's network -- and a foreigner to Company A's. A few recent VPN implementations provide "split tunnelling" to provide the access you expect. Typically, when the client connects to the server, the server tells it whether split tunnelling is permitted or not. I suspect that many security admins will be very reluctant to permit it, even when the client is capable of supporting it. David Gillett Enterprise Networking Services Manager, Niku Corp. (650) 701-2702 "Transforming the Service Economy" -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of David Rudolph Sent: Tuesday, September 19, 2000 5:42 AM To: VPN at SECURITYFOCUS.COM Subject: VPN disables access to local corporate LAN I'm new to VPN, and I'm looking for some help in getting things set up. The basic problem is that, as soon as I connect to the VPN, I lose access to my local corporate LAN. Here the details. I am working at Company A, and am attached physically to their corporate LAN. I'm trying to connect to Company B using VPN. As soon as I dial, and get connected to Company B, I no longer seem to be able to access anything on Company A's LAN. For example, my mail client can no longer find the mail server, and telnet can no longer find any of the machines on the local LAN. I'm running Windows NT 4.0, service pack 6. Is there any way around this? ---------------------------------------------------------------------------- David Rudolph | phone: (781) 466-8370 Mitsubishi Electric Research Labs | email: rudolph at merl.com ---------------------------------------------------------------------------- VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From vampier at MAC.COM Tue Sep 19 15:26:16 2000 From: vampier at MAC.COM (Andrew Chen) Date: Tue, 19 Sep 2000 15:26:16 -0400 Subject: Fwd: TechTip: What's a VPN, Anyway? Message-ID: I found this on SearchSecurity.com's mailing list - thought it might be a relevant reply to David Rudolph's "VPN disables access to local corporate LAN" message. >Subject: TechTip: What's a VPN, Anyway? >Date: Tue, 19 Sep 2000 15:20:45 -0400 > >------------------------------------------------ >SearchSecurity.com's Tech Tip >------------------------------------------------ > >TODAY'S TECH TIP: What's a VPN, Anyway? > >************************************************************* > >What's a VPN, Anyway? >by David Gabel > >There is a lot of confusion and downright obfuscation about the >subject of VPNs. They are, apparently, different things to different >people, especially to vendors with their own VPN products to sell. >This tip, excerpted from Microsoft Windows 2000 Security Handbook, >by Jeff Schmidt and Dave Bixler (published by Que >, ISBN 0789719991), defines a VPN and >discusses some of the applications for one. > >************************************************************* >A VPN is a mechanism for providing secure, encrypted communications >in two configurations. First, a user to network configuration, where >the remote user connects to the Internet and using a VPN is able to >securely become a node on the company network. This is commonly >referred to as the "Remote Access" model for a VPN. The other >configuration is when a site/office uses the VPN coupled with an >Internet connection to securely connect to the network at the other >end of the VPN. This is commonly referred to as a "site to site" >VPN. The remote access VPN is used to supplant the standard remote >access of dial in or authenticated firewall access to the network. >The site to site model is being used in places to remove the need >for a Wide Area Network. Both configurations can offer significant >cost savings over the more traditional access methods. One downside >of the VPN model however, is during Internet backbone outages. When >you are unable to connect to your office because one of the Tier 1 >networks has suffered a fiber cut, whom can you call? With a WAN or >a remote access solution you always had a vendor you could call for >a status, or to have a technician dispatched. There is no >1-800-INTERNET number that you can call for technical support. This >is the major tradeoff with a VPN solution versus a more traditional >approach. > >These are two of the more common uses for a VPN, but they are not >the only reasons to use VPN technologies. Without security, both >public and private networks are susceptible to unauthorized >monitoring and access. That's right...private networks are >susceptible to security issues just like the public Internet is. >Welcome to networking in the 90's. Do you think your internal >security breaches are just the result of minimal or nonexistent >internal network security? Are you convinced that the major risks to >your network are from outside the private network; in other words >from connections to the Internet and any extranets connecting your >network to customers or vendors? Guess again. A disgruntled employee >with an easily downloaded packet sniffer can be a much larger issue >than any Internet connection. Password-secured systems cannot >protect data transmitted across a network. > >To read more of this book, click to InformIT at: >http://www.informit.com/product/0789719991/ > >David Gabel is Executive Technology Editor at Techtarget.com. > >======================================================== >Site Editor's Note: Do you find the items we've researched in this >newsletter helpful? Tell us about it. If you have suggestions or >comments on other topics you would like to see covered on our >SearchSecurity.com site or in an upcoming newsletter, we'd like to >hear from you. Please send an e-mail to me directly: Cathleen Gagne, >SearchSecurity.com site editor, at mailto:cgagne at techtarget.com. >(NOTE: If you would like to be removed from this e-mail list, please >follow the instructions below and reply directly to this e-mail from >SearchSecurity.com.) >========================================================= > >This message is being sent to you by http://www.SearchSecurity.com >GET RELEVANT SEARCH RESULTS from 2000 security-specific websites chosen by our >editorial team for quality and relevance. > >If you prefer not to receive further messages from this sender, >"Reply" to this >message with REMOVE in the subject line. You will receive a >confirmation email. VPN is sponsored by SecurityFocus.COM From SJalali at EMETEK.COM Tue Sep 19 16:42:11 2000 From: SJalali at EMETEK.COM (Saeed Jalali) Date: Tue, 19 Sep 2000 13:42:11 -0700 Subject: VPN disables access to local corporate LAN Message-ID: It's because your VPN client is putting a default route in your routing tables that is sending all your IP traffic through the VPN. > -----Original Message----- > From: David Rudolph [mailto:rudolph at MEITCA.COM] > Sent: Tuesday, September 19, 2000 5:42 AM > To: VPN at SECURITYFOCUS.COM > Subject: VPN disables access to local corporate LAN > > > I'm new to VPN, and I'm looking for some help in getting > things set up. > The basic problem is that, as soon as I connect to the VPN, I lose > access to my local corporate LAN. > > Here the details. I am working at Company A, and am attached > physically > to their corporate LAN. I'm trying to connect to Company B > using VPN. As > soon as I dial, and get connected to Company B, I no longer seem to be > able to access anything on Company A's LAN. For example, my > mail client > can no longer find the mail server, and telnet can no longer > find any of > the machines on the local LAN. I'm running Windows NT 4.0, > service pack > 6. Is there any way around this? > > > > -------------------------------------------------------------- > -------------- > > David Rudolph | phone: (781) 466-8370 > Mitsubishi Electric Research Labs | email: > rudolph at merl.com > > -------------------------------------------------------------- > -------------- > > VPN is sponsored by SecurityFocus.COM > VPN is sponsored by SecurityFocus.COM From chost at LANL.GOV Tue Sep 19 15:57:13 2000 From: chost at LANL.GOV (Cheryl Host) Date: Tue, 19 Sep 2000 13:57:13 -0600 Subject: VPN disables access to local corporate LAN References: <39C75F2B286.6202RUDOLPH@dpw.meitca.com> Message-ID: <008c01c02273$cda85b40$1672a580@lanl.gov> It sounds like your VPN gateway is configured to tunnel all traffic. In this case, when a tunnel is up all traffic goes through Company B. Company A probably has a firewall which does not allow company B traffic in. On our Intel/Shiva LanRover, this is configured by using a net-include statement with all zeros for the subnet and mask. (0.0.0.0 0.0.0.0) ----- Original Message ----- From: "David Rudolph" To: Sent: Tuesday, September 19, 2000 6:42 AM Subject: VPN disables access to local corporate LAN > I'm new to VPN, and I'm looking for some help in getting things set up. > The basic problem is that, as soon as I connect to the VPN, I lose > access to my local corporate LAN. > > Here the details. I am working at Company A, and am attached physically > to their corporate LAN. I'm trying to connect to Company B using VPN. As > soon as I dial, and get connected to Company B, I no longer seem to be > able to access anything on Company A's LAN. For example, my mail client > can no longer find the mail server, and telnet can no longer find any of > the machines on the local LAN. I'm running Windows NT 4.0, service pack > 6. Is there any way around this? > > > > -------------------------------------------------------------------------- -- > > David Rudolph | phone: (781) 466-8370 > Mitsubishi Electric Research Labs | email: rudolph at merl.com > > -------------------------------------------------------------------------- -- > > VPN is sponsored by SecurityFocus.COM > VPN is sponsored by SecurityFocus.COM From jonc at HAHT.COM Tue Sep 19 15:18:43 2000 From: jonc at HAHT.COM (Jon Carnes) Date: Tue, 19 Sep 2000 15:18:43 -0400 Subject: VPN disables access to local corporate LAN References: <39C75F2B286.6202RUDOLPH@dpw.meitca.com> Message-ID: <00f601c0226e$6de75d00$6803010a@dhcp.haht.com> Open a dos box and do a "route print" before connecting via the vpn, and then one right after. The problem will become apparent (if you know how to interpret routing tables). Assuming that the company your attaching to has a different ip network from yours, the problem with be with your 0.0.0.0 route. This is the default route used on your machine. In the TCP/IP settings of your PPTP dial-up make sure that the box for "Use default gateway on remote network" is unchecked. It's also possible that they are using the same internal addressing as you. Sometimes you can play around with the subnet masks to make things work. In any case this is most likely a routing problem. I've solved these a lot, and you can almost always get full functionality by writing some easy batch files that setup specific routes to the resources you are trying to access - rather than general routes that mirror your own network. Jon Carnes MIS - HAHT Commerce ----- Original Message ----- From: "David Rudolph" To: Sent: Tuesday, September 19, 2000 8:42 AM Subject: VPN disables access to local corporate LAN > I'm new to VPN, and I'm looking for some help in getting things set up. > The basic problem is that, as soon as I connect to the VPN, I lose > access to my local corporate LAN. > > Here the details. I am working at Company A, and am attached physically > to their corporate LAN. I'm trying to connect to Company B using VPN. As > soon as I dial, and get connected to Company B, I no longer seem to be > able to access anything on Company A's LAN. For example, my mail client > can no longer find the mail server, and telnet can no longer find any of > the machines on the local LAN. I'm running Windows NT 4.0, service pack > 6. Is there any way around this? > > > > -------------------------------------------------------------------------- -- > > David Rudolph | phone: (781) 466-8370 > Mitsubishi Electric Research Labs | email: rudolph at merl.com > > -------------------------------------------------------------------------- -- > > VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From jsdy at COSPO.OSIS.GOV Tue Sep 19 17:54:34 2000 From: jsdy at COSPO.OSIS.GOV (Joseph S D Yao) Date: Tue, 19 Sep 2000 17:54:34 -0400 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: ; from vampier@MAC.COM on Tue, Sep 19, 2000 at 03:26:16PM -0400 References: Message-ID: <20000919175434.C5624@washington.cospo.osis.gov> On Tue, Sep 19, 2000 at 03:26:16PM -0400, Andrew Chen wrote: > I found this on SearchSecurity.com's mailing list - thought it might > be a relevant reply to David Rudolph's "VPN disables access to local > corporate LAN" message. > > >Subject: TechTip: What's a VPN, Anyway? > >Date: Tue, 19 Sep 2000 15:20:45 -0400 More directly to the point ... Mr. Rudolph's VPN client is behaving the way a VPN client should, to maximize VPN/LAN security. If his machine could be on both the local LAN and the remote LAN simultaneously, it could conceivably form a bridge of some kind between the two. If his machine is locked down so that it only appears to be on one of the two networks at a time, this risk is reduced. Most - I am told, all - IPsec clients used to allow this kind of dual access. I understand that more either don't allow it, or allow the VPNmeister to specify whether it is allowed. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM From guy.raymakers at EDS.COM Wed Sep 20 04:18:24 2000 From: guy.raymakers at EDS.COM (Raymakers, Guy) Date: Wed, 20 Sep 2000 09:18:24 +0100 Subject: WTLS Message-ID: Dear colleagues, Looking at SSL, I came across WTLS. WTLS is the wireless version of the Transport Layer Security protocol. Basically it should solve the problems SSL (TLS) is having on high latency networks (e.g. satellite links). Does anyone know something more about this protocol or is even using this ? Thanks & best regards, Guy VPN is sponsored by SecurityFocus.COM From dgillett at NIKU.COM Tue Sep 19 19:14:31 2000 From: dgillett at NIKU.COM (David Gillett) Date: Tue, 19 Sep 2000 16:14:31 -0700 Subject: VPN disables access to local corporate LAN In-Reply-To: Message-ID: <003f01c0228f$6032e5f0$f30410ac@niku.com> Not to pick on Larry here -- at least three responses have suggested that this has something to do with the "default route". It doesn't. It CAN'T. Because the default route, in order to be "default", applies at the *end* of the route table, after all other possibilities have been considered. The forced tunnelling applies (effectively) *before* the route table. David Gillett Enterprise Networking Services Manager, Niku Corp. (650) 701-2702 "Transforming the Service Economy" -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Larry Thompson Sent: Tuesday, September 19, 2000 11:53 AM To: VPN at SECURITYFOCUS.COM Subject: FW: VPN disables access to local corporate LAN Uncheck the box in the dial settings to use the dial connection as the default gateway. VPN is sponsored by SecurityFocus.COM From rudolph at MEITCA.COM Wed Sep 20 09:05:29 2000 From: rudolph at MEITCA.COM (David Rudolph) Date: Wed, 20 Sep 2000 06:05:29 -0700 Subject: VPN disables access to local corporate LAN In-Reply-To: <00f601c0226e$6de75d00$6803010a@dhcp.haht.com> References: <39C75F2B286.6202RUDOLPH@dpw.meitca.com> <00f601c0226e$6de75d00$6803010a@dhcp.haht.com> Message-ID: <39C8B6192E6.6209RUDOLPH@dpw.meitca.com> On Tue, 19 Sep 2000 15:18:43 -0400 Jon Carnes wrote: > Open a dos box and do a "route print" before connecting via the vpn, and > then one right after. The problem will become apparent (if you know how to > interpret routing tables). > > Assuming that the company your attaching to has a different ip network from > yours, the problem with be with your 0.0.0.0 route. This is the default > route used on your machine. In the TCP/IP settings of your PPTP dial-up > make sure that the box for "Use default gateway on remote network" is > unchecked. > Thanks to all who replied. As John (and Larry Thompson also) mentioned, it was as simple as unchecking the "use default gateway" box. dave VPN is sponsored by SecurityFocus.COM From binky at CERTAINTYSOLUTIONS.COM Tue Sep 19 22:43:18 2000 From: binky at CERTAINTYSOLUTIONS.COM (Michael Batchelder) Date: Tue, 19 Sep 2000 19:43:18 -0700 Subject: VPN disables access to local corporate LAN References: Message-ID: <39C82446.4359D0C5@certaintysolutions.com> It's more than just routing, most likely. It's probably the split tunneling functionality that was mentioned already by a couple people. A number of VPN clients do this, though David doesn't mention which VPN client he's using. But it's not strictly a matter of manipulating routing tables. In particular, if you *just* tweaked a default route, at minimum the locally connected network would still be available, and possibly others with static routes. There's two models of VPN client/adapter, generally speaking--ones that shim themselves into existing TCP/IP stacks, and ones that build all their own. Depending on the model, you'd implement split tunneling in different ways, I would think. Michael Saeed Jalali wrote: > > It's because your VPN client is putting a default > route in your routing tables that is sending > all your IP traffic through the VPN. > > > -----Original Message----- > > From: David Rudolph [mailto:rudolph at MEITCA.COM] > > Sent: Tuesday, September 19, 2000 5:42 AM > > To: VPN at SECURITYFOCUS.COM > > Subject: VPN disables access to local corporate LAN > > > > > > I'm new to VPN, and I'm looking for some help in getting > > things set up. > > The basic problem is that, as soon as I connect to the VPN, I lose > > access to my local corporate LAN. > > > > Here the details. I am working at Company A, and am attached > > physically > > to their corporate LAN. I'm trying to connect to Company B > > using VPN. As > > soon as I dial, and get connected to Company B, I no longer seem to be > > able to access anything on Company A's LAN. For example, my > > mail client > > can no longer find the mail server, and telnet can no longer > > find any of > > the machines on the local LAN. I'm running Windows NT 4.0, > > service pack > > 6. Is there any way around this? > > > > > > > > -------------------------------------------------------------- > > -------------- > > > > David Rudolph | phone: (781) 466-8370 > > Mitsubishi Electric Research Labs | email: > > rudolph at merl.com > > > > -------------------------------------------------------------- > > -------------- > > > > VPN is sponsored by SecurityFocus.COM > > > > VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From nick at VDWALT.COM Wed Sep 20 05:02:44 2000 From: nick at VDWALT.COM (Nick van der Walt) Date: Wed, 20 Sep 2000 13:02:44 +0400 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: <20000919175434.C5624@washington.cospo.osis.gov> Message-ID: Hi all I am about to venture into the VPN world. I am about to start the project of implementing a VPN on an international base. Saying this here is an explanation of my company setup. I am working for an international concern that is currently running a leased line dedicated WAN from office to office. My aim is to terminate the current WAN links and migrate to a VPN infrastructure. The equipment I am currently evaluating is Cisco's 2650 routers with VPN cards, and dedicated Internet connections. I am not using a VPN dial up structure but dedicated Connections. Any suggestions on pitfalls I should be aware off............? What are the implications of implementing VOIP on top of this VPN structure? Nick -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Joseph S D Yao Sent: Wednesday, September 20, 2000 1:55 AM To: VPN at SECURITYFOCUS.COM Subject: Re: Fwd: TechTip: What's a VPN, Anyway? On Tue, Sep 19, 2000 at 03:26:16PM -0400, Andrew Chen wrote: > I found this on SearchSecurity.com's mailing list - thought it might > be a relevant reply to David Rudolph's "VPN disables access to local > corporate LAN" message. > > >Subject: TechTip: What's a VPN, Anyway? > >Date: Tue, 19 Sep 2000 15:20:45 -0400 More directly to the point ... Mr. Rudolph's VPN client is behaving the way a VPN client should, to maximize VPN/LAN security. If his machine could be on both the local LAN and the remote LAN simultaneously, it could conceivably form a bridge of some kind between the two. If his machine is locked down so that it only appears to be on one of the two networks at a time, this risk is reduced. Most - I am told, all - IPsec clients used to allow this kind of dual access. I understand that more either don't allow it, or allow the VPNmeister to specify whether it is allowed. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From lthompson at IRE.COM Wed Sep 20 13:01:03 2000 From: lthompson at IRE.COM (Larry Thompson) Date: Wed, 20 Sep 2000 13:01:03 -0400 Subject: FW: VPN disables access to local corporate LAN Message-ID: READ THE RESPONSES....IT FIXED IT !!!!! -----Original Message----- From: David Gillett [mailto:dgillett at NIKU.COM] Sent: Tuesday, September 19, 2000 7:15 PM To: VPN at SECURITYFOCUS.COM Subject: Re: VPN disables access to local corporate LAN Not to pick on Larry here -- at least three responses have suggested that this has something to do with the "default route". It doesn't. It CAN'T. Because the default route, in order to be "default", applies at the *end* of the route table, after all other possibilities have been considered. The forced tunnelling applies (effectively) *before* the route table. David Gillett Enterprise Networking Services Manager, Niku Corp. (650) 701-2702 "Transforming the Service Economy" -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Larry Thompson Sent: Tuesday, September 19, 2000 11:53 AM To: VPN at SECURITYFOCUS.COM Subject: FW: VPN disables access to local corporate LAN Uncheck the box in the dial settings to use the dial connection as the default gateway. VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From bet at RAHUL.NET Wed Sep 20 12:58:04 2000 From: bet at RAHUL.NET (Bennett Todd) Date: Wed, 20 Sep 2000 12:58:04 -0400 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: ; from nick@VDWALT.COM on Wed, Sep 20, 2000 at 01:02:44PM +0400 References: <20000919175434.C5624@washington.cospo.osis.gov> Message-ID: <20000920125804.O723@oven.com> 2000-09-20-05:02:44 Nick van der Walt: > I am working for an international concern that is currently running a leased > line dedicated WAN from office to office. My aim is to terminate the current > WAN links and migrate to a VPN infrastructure. If you mean to run your VPN over the public internet (which I'd assume from your mention of terminating your WAN links), I'd advise against it myself. I think the best setup is to run a VPN over private WAN links, with one or more exceedingly carefully managed firewalls controlling access to one or more points of access to the public internet. The problem with replacing the private WAN with VPN-over-internet, is that the internet delivers neither the performance, nor the reliability, nor the stability of a private WAN. A decently managed private WAN should have exceedingly reliable and consistent performance, which you'll never get out of the internet. Now one thing that can be truly sweet is to have your VPN rigged to failover to tunnels through the internet to provide backup connectivity if your WAN links fail, but that's a very different matter; it just involves your in-house net crashing 90% of the way down, rather than all the way. We are going the other direction; we've grown an in-house net with VPN-over-internet interconnecting our offices, and we're adding WAN links to the VPN to improve reliability and performance. I think you'll be _amazingly_ disappointed at the usability of Voice-over-IP carried over a VPN over the internet; sound files in PGP-encrypted email would be a lot more useable. I'd expect VoIP over VPN over internet to be rather worse than subway/drivethrough speaker systems, with more dropouts than usable sound. -Bennett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.shmoo.com/pipermail/vpn/attachments/20000920/440d0c52/attachment.pgp From dgillett at NIKU.COM Wed Sep 20 14:00:28 2000 From: dgillett at NIKU.COM (David Gillett) Date: Wed, 20 Sep 2000 11:00:28 -0700 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: Message-ID: <005401c0232c$aa639500$f30410ac@niku.com> There are two caveats that immediately leap out at me: 1. Most of the reliability and performance problems I've seen on site-to-site VPNs have been with the peering gateways between different ISPs and backbone providers. I recommend that you select an ISP who can serve all of your locations, and get an SLA (Service Level Agreement) with them. 2. VOIP relies on timely delivery, and Cisco's preferred way to ensure this is to use QoS extensions on IP. This could run you into difficulties over three issues: a. VPN encapsulation probably hides the QoS bits of the packets -- voice gets no special treatment. b. It appears that an IPSEC tunnel can experience significant delays while recovering from a lost packet. This may not be acceptable for voice traffic -- although I've usually seen this at peering points (see 1 above). c. I'm not sure Cisco implements QoS on anything below their 38xx series. That's what they've been telling us we should be buying to do VoIP.... David Gillett Enterprise Networking Services Manager, Niku Corp. (650) 701-2702 "Transforming the Service Economy" -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Nick van der Walt Sent: Wednesday, September 20, 2000 2:03 AM To: VPN at SECURITYFOCUS.COM Subject: Re: Fwd: TechTip: What's a VPN, Anyway? Hi all I am about to venture into the VPN world. I am about to start the project of implementing a VPN on an international base. Saying this here is an explanation of my company setup. I am working for an international concern that is currently running a leased line dedicated WAN from office to office. My aim is to terminate the current WAN links and migrate to a VPN infrastructure. The equipment I am currently evaluating is Cisco's 2650 routers with VPN cards, and dedicated Internet connections. I am not using a VPN dial up structure but dedicated Connections. Any suggestions on pitfalls I should be aware off............? What are the implications of implementing VOIP on top of this VPN structure? Nick -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Joseph S D Yao Sent: Wednesday, September 20, 2000 1:55 AM To: VPN at SECURITYFOCUS.COM Subject: Re: Fwd: TechTip: What's a VPN, Anyway? On Tue, Sep 19, 2000 at 03:26:16PM -0400, Andrew Chen wrote: > I found this on SearchSecurity.com's mailing list - thought it might > be a relevant reply to David Rudolph's "VPN disables access to local > corporate LAN" message. > > >Subject: TechTip: What's a VPN, Anyway? > >Date: Tue, 19 Sep 2000 15:20:45 -0400 More directly to the point ... Mr. Rudolph's VPN client is behaving the way a VPN client should, to maximize VPN/LAN security. If his machine could be on both the local LAN and the remote LAN simultaneously, it could conceivably form a bridge of some kind between the two. If his machine is locked down so that it only appears to be on one of the two networks at a time, this risk is reduced. Most - I am told, all - IPsec clients used to allow this kind of dual access. I understand that more either don't allow it, or allow the VPNmeister to specify whether it is allowed. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From jonc at HAHT.COM Wed Sep 20 15:02:27 2000 From: jonc at HAHT.COM (Jon Carnes) Date: Wed, 20 Sep 2000 15:02:27 -0400 Subject: VPN disables access to local corporate LAN References: <003f01c0228f$6032e5f0$f30410ac@niku.com> Message-ID: <00e301c02335$52268970$6803010a@dhcp.haht.com> David, you're thinking "two dimensionally". You would be easy prey for Khan. Corporate networks are not always flat. Our particular network has most vital systems isolated on their own net, and traffic is "firewalled" to the general population. In our case, we don't give each individual machine a map to each internal network, instead each machine uses the "internal firewall" as its gateway. It works. We also have several other internal networks which are somewhat isolated - most notably: training and QA. Lose of the default route would cause an internal machine to no longer have access to internal corporate servers. Larry, you're doing great. Glad things are working for you again! Jon Carnes MIS - HAHT Commerce ----- Original Message ----- From: "David Gillett" To: Sent: Tuesday, September 19, 2000 7:14 PM Subject: Re: VPN disables access to local corporate LAN > Not to pick on Larry here -- at least three responses have suggested that > this has something to do with the "default route". > > It doesn't. It CAN'T. Because the default route, in order to be > "default", applies at the *end* of the route table, after all other > possibilities have been considered. The forced tunnelling applies > (effectively) *before* the route table. > > David Gillett > Enterprise Networking Services Manager, Niku Corp. > (650) 701-2702 > "Transforming the Service Economy" > > > > -----Original Message----- > From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Larry > Thompson > Sent: Tuesday, September 19, 2000 11:53 AM > To: VPN at SECURITYFOCUS.COM > Subject: FW: VPN disables access to local corporate LAN > > > Uncheck the box in the dial settings to use the dial connection as the > default gateway. > > VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From Ian.Moran at KONNEXION.COM Wed Sep 20 16:45:03 2000 From: Ian.Moran at KONNEXION.COM (Ian Moran) Date: Wed, 20 Sep 2000 21:45:03 +0100 Subject: Fwd: TechTip: What's a VPN, Anyway? Message-ID: My experience differs. I've established a VPN over internet connections from our Belfast office to our Atlanta & Brussels office and performance and reliability has been excellent in the 6 months this has been running. Ian > -----Original Message----- > From: Bennett Todd [mailto:bet at RAHUL.NET] > Sent: 20 September 2000 17:58 > To: VPN at SECURITYFOCUS.COM > Subject: Re: Fwd: TechTip: What's a VPN, Anyway? > > > 2000-09-20-05:02:44 Nick van der Walt: > > I am working for an international concern that is currently > running a leased > > line dedicated WAN from office to office. My aim is to > terminate the current > > WAN links and migrate to a VPN infrastructure. > > If you mean to run your VPN over the public internet (which I'd > assume from your mention of terminating your WAN links), I'd advise > against it myself. > > I think the best setup is to run a VPN over private WAN links, with > one or more exceedingly carefully managed firewalls controlling > access to one or more points of access to the public internet. > > The problem with replacing the private WAN with VPN-over-internet, > is that the internet delivers neither the performance, nor the > reliability, nor the stability of a private WAN. A decently managed > private WAN should have exceedingly reliable and consistent > performance, which you'll never get out of the internet. > > Now one thing that can be truly sweet is to have your VPN rigged to > failover to tunnels through the internet to provide backup > connectivity if your WAN links fail, but that's a very different > matter; it just involves your in-house net crashing 90% of the way > down, rather than all the way. > > We are going the other direction; we've grown an in-house net with > VPN-over-internet interconnecting our offices, and we're adding WAN > links to the VPN to improve reliability and performance. > > I think you'll be _amazingly_ disappointed at the usability of > Voice-over-IP carried over a VPN over the internet; sound files in > PGP-encrypted email would be a lot more useable. I'd expect VoIP > over VPN over internet to be rather worse than subway/drivethrough > speaker systems, with more dropouts than usable sound. > > -Bennett > VPN is sponsored by SecurityFocus.COM From jsdy at COSPO.OSIS.GOV Wed Sep 20 19:30:09 2000 From: jsdy at COSPO.OSIS.GOV (Joseph S D Yao) Date: Wed, 20 Sep 2000 19:30:09 -0400 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: ; from Ian.Moran@konnexion.com on Wed, Sep 20, 2000 at 09:45:03PM +0100 References: Message-ID: <20000920193009.S12272@washington.cospo.osis.gov> On Wed, Sep 20, 2000 at 09:45:03PM +0100, Ian Moran wrote: > My experience differs. I've established a VPN over internet connections > from our Belfast office to our Atlanta & Brussels office and performance > and reliability has been excellent in the 6 months this has been > running. > > Ian Are you using the same ISP at each site, e.g., UUNet? -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM From jsdy at COSPO.OSIS.GOV Thu Sep 21 13:18:45 2000 From: jsdy at COSPO.OSIS.GOV (Joseph S D Yao) Date: Thu, 21 Sep 2000 13:18:45 -0400 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: ; from Ian.Moran@konnexion.com on Thu, Sep 21, 2000 at 06:05:03PM +0100 References: Message-ID: <20000921131845.U20898@washington.cospo.osis.gov> On Thu, Sep 21, 2000 at 06:05:03PM +0100, Ian Moran wrote: > I wish I was - makes good sense to do so. The Belfast & Brussels sites > use UUnet, the Atlanta site uses AT&T (not my choice I hasten to add) > > Ian I think they have good peering, though. The point that was being made was that there are problems at SOME peering points. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM From Charles.Clayton at EQUIFAX.COM Thu Sep 21 11:10:59 2000 From: Charles.Clayton at EQUIFAX.COM (Charles.Clayton at EQUIFAX.COM) Date: Thu, 21 Sep 2000 11:10:59 -0400 Subject: Difference Between SSL v.2 and v.3 Message-ID: <85256961.005373C6.00@noteswetc15.fin.equifax.com> Hello all, Can anyone point me to a mod list of the differences between SSL v.2 and v.3? Thanx in advance, Charlie Clayton, CISSP * * * * * * * This message contains information from Equifax, Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify PostMaster at Equifax.com. This message and any attachments have been scanned for viruses. VPN is sponsored by SecurityFocus.COM From guy.raymakers at EDS.COM Thu Sep 21 05:29:55 2000 From: guy.raymakers at EDS.COM (Raymakers, Guy) Date: Thu, 21 Sep 2000 10:29:55 +0100 Subject: WTLS Message-ID: Yes, I've read it in combination with WAP. I'm wondering whether this also would be available to use for 'normal' web appliactions over the Internet. Best regards, Guy -----Original Message----- From: Magos?nyi ?rp?d [mailto:mag at bunuel.tii.matav.hu] Sent: donderdag 21 september 2000 10:24 To: Raymakers, Guy Subject: Re: [VPN] WTLS A levelez?m azt hiszi, hogy Raymakers, Guy a k?vetkez?eket ?rta: > Dear colleagues, > > Looking at SSL, I came across WTLS. WTLS is the wireless version of the > Transport Layer Security protocol. Basically it should solve the problems > SSL (TLS) is having on high latency networks (e.g. satellite links). Does > anyone know something more about this protocol or is even using this ? Isn't it the one used by/with WAP? -- GNU GPL: csak tiszta forr?sb?l VPN is sponsored by SecurityFocus.COM From nick at VDWALT.COM Thu Sep 21 11:56:55 2000 From: nick at VDWALT.COM (Nick van der Walt) Date: Thu, 21 Sep 2000 19:56:55 +0400 Subject: Fwd: TechTip: What's a VPN, Anyway? In-Reply-To: <20000920193009.S12272@washington.cospo.osis.gov> Message-ID: Hey Joseph I am writing a SLA with an international ISP that would service all our offices. In most of our locations like USA, Singapore and European offices I have no problem in installing a T1 link to an Internet exchange, as this is not costly at all. The problem I am experiencing is in South Africa as well as UAE where T1 links cost an absolute fortune, which leaves me with no choice but to downgrade my speed to 256k. For all my other responses I got I would like to say: THANKS I am most impressed with the speed in which I got the responses...........some of you asked me questions and here are my answers......... Todd Bennette Your apprehensions are quite real, but I have to look at this situation regardless. I have (as mentioned above) investigated an International ISP whom could give me a guaranteed international bandwidth from all my sites. As a first phase I will be installing the VPN infrastructure and as a second the VOIP. This will only happen once I am comfortable with the reliability and speed of the VPN. As the cost involved in this exercise proves to be millions of $$$$$$$$$$$ I am in quite a good situation to demand.......... I will however keep you updated as the project goes along.......... David Gillett I hope the above has answered your questions. The ISP is international and looking after all my sites. And my SLA with this ISP will serve to its full capacity. Cisco has only recently released their 2650 model, which I have been waiting for. I will however run this in a test environment before going live... Another question................. One of my sites (and several more to come) is located in geographical locations such as islands, which has no telecom infrastructure at all. I am using VSAT links as well as Microwave links to the closest earth station and from there will be tying up via VPN to our corporate backbone. My experience in VSAT and Microwave is very extensive, but the tricky part is where these two topologies connect to carry an IPSEC tunnel to a VPN infrastructure. Any hints?. Nick -----Original Message----- From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Joseph S D Yao Sent: Thursday, September 21, 2000 3:30 AM To: VPN at SECURITYFOCUS.COM Subject: Re: Fwd: TechTip: What's a VPN, Anyway? On Wed, Sep 20, 2000 at 09:45:03PM +0100, Ian Moran wrote: > My experience differs. I've established a VPN over internet connections > from our Belfast office to our Atlanta & Brussels office and performance > and reliability has been excellent in the 6 months this has been > running. > > Ian Are you using the same ISP at each site, e.g., UUNet? -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM VPN is sponsored by SecurityFocus.COM From shope at ENERGIS-EIS.CO.UK Thu Sep 21 04:15:36 2000 From: shope at ENERGIS-EIS.CO.UK (Stephen Hope) Date: Thu, 21 Sep 2000 09:15:36 +0100 Subject: Fwd: TechTip: What's a VPN, Anyway? Message-ID: <01903665B361D211BF6700805FAD5D93591B72@mail.datarange.co.uk> just my 2p worth..... The cisco router code generally supports Qos, and some of the more recent models have voice interfaces. e.g 1750 and 2600 have analog, "a few" voice ports, targeted at a branch. the 36xx range support analog and digital (E1 or T1) voice the 72xx and 75xx support digital only. All the routers support VoIP, and Voice over Frame, and Voice over ATM where the router has a native ATM interface. I have used the 3640 and 3660 with analog voice already and we are installing the E1 PRI voice - it works pretty well (apart from all those proprietary voice signalling standards which are a real pain). Re the QoS over VPN - i have been told a cisco guru that the IPSec and GRE implementations in some code versions will copy the priority fields (Diffserv) into the header at encapsulation time - of course this doesnt mean that any of the kit can or is configured to take any notice...... My preference is to use voice encapsulation in this way only over private networks, and preferably Frame or ATM - but i have had my fingers burned with similar "vague SLA" type issues before from carriers and ISPs. If you get a technical engineer from all the major manufacturers and ask for recommendations rather than "i want to do this - will it work" - then the answer i frequently get is VoIP and similar technologies need: a reasonably well controlled infrastructure to run over. bounded latency, probably using QoS techniques. low packet loss for the voice traffic. bandwidth headroom. You need to decide if the SLA you can get from a worldwide ISP matches those requirements, especially after your VPN gear has massaged the dat to provide the security and tunnelling that you need - my first guess would be that this is a borderline case with all the delays you are considering (ISP latency and QoS, distance, voice encoding, VPN encapsulation). There is also voice support on other cisco kit such as gateways and RAS gear like the 5300. Stephen Stephen Hope C. Eng, Network Consultant, shope at energis-eis.co.uk, Energis Integration Services Ltd, WWW: http://www.energis-eis.co.uk Carrington Business Park, Carrington, Manchester , UK. M31 4ZU Tel: +44 (0)161 776 4190 Mob: +44 (0)7767 256 180 Fax: +44 (0)161 776 4189 > -----Original Message----- > From: David Gillett [mailto:dgillett at NIKU.COM] > Sent: Wednesday, September 20, 2000 7:00 PM > To: VPN at SECURITYFOCUS.COM > Subject: Re: Fwd: TechTip: What's a VPN, Anyway? > > > There are two caveats that immediately leap out at me: > > 1. Most of the reliability and performance problems I've seen on > site-to-site VPNs have been with the peering gateways between > different ISPs > and backbone providers. I recommend that you select an ISP > who can serve > all of your locations, and get an SLA (Service Level > Agreement) with them. > > 2. VOIP relies on timely delivery, and Cisco's preferred way > to ensure this > is to use QoS extensions on IP. This could run you into > difficulties over > three issues: > > a. VPN encapsulation probably hides the QoS bits of the > packets -- voice > gets no special treatment. > > b. It appears that an IPSEC tunnel can experience > significant delays > while recovering from a lost packet. This may not be > acceptable for voice > traffic -- although I've usually seen this at peering points > (see 1 above). > > c. I'm not sure Cisco implements QoS on anything below > their 38xx series. > That's what they've been telling us we should be buying to do VoIP.... > > David Gillett > Enterprise Networking Services Manager, Niku Corp. > (650) 701-2702 > "Transforming the Service Economy" > > > > -----Original Message----- > From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On Behalf Of Nick > van der Walt > Sent: Wednesday, September 20, 2000 2:03 AM > To: VPN at SECURITYFOCUS.COM > Subject: Re: Fwd: TechTip: What's a VPN, Anyway? > > > Hi all > > I am about to venture into the VPN world. I am about to start > the project of > implementing a VPN on an international base. Saying this here is an > explanation of my company setup. > > I am working for an international concern that is currently > running a leased > line dedicated WAN from office to office. My aim is to > terminate the current > WAN links and migrate to a VPN infrastructure. > > The equipment I am currently evaluating is Cisco's 2650 > routers with VPN > cards, and dedicated Internet connections. I am not using a > VPN dial up > structure but dedicated > Connections. > > Any suggestions on pitfalls I should be aware off............? > > What are the implications of implementing VOIP on top of this > VPN structure? > > > Nick > -----Original Message----- > From: VPN Mailing List [mailto:VPN at SECURITYFOCUS.COM]On > Behalf Of Joseph S D > Yao > Sent: Wednesday, September 20, 2000 1:55 AM > To: VPN at SECURITYFOCUS.COM > Subject: Re: Fwd: TechTip: What's a VPN, Anyway? > > On Tue, Sep 19, 2000 at 03:26:16PM -0400, Andrew Chen wrote: > > I found this on SearchSecurity.com's mailing list - thought it might > > be a relevant reply to David Rudolph's "VPN disables access to local > > corporate LAN" message. > > > > >Subject: TechTip: What's a VPN, Anyway? > > >Date: Tue, 19 Sep 2000 15:20:45 -0400 > > More directly to the point ... Mr. Rudolph's VPN client is > behaving the > way a VPN client should, to maximize VPN/LAN security. If his machine > could be on both the local LAN and the remote LAN simultaneously, it > could conceivably form a bridge of some kind between the two. If his > machine is locked down so that it only appears to be on one of the two > networks at a time, this risk is reduced. > > Most - I am told, all - IPsec clients used to allow this kind of dual > access. I understand that more either don't allow it, or allow the > VPNmeister to specify whether it is allowed. > > -- > Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao > COSPO/OSIS Computer Support EMT-B > -------------------------------------------------------------- > --------- > This message is not an official statement of COSPO policies. > > VPN is sponsored by SecurityFocus.COM > > VPN is sponsored by SecurityFocus.COM > > VPN is sponsored by SecurityFocus.COM > ----------------------------------------------------------------------------------------------------------- This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Energis Integration Services. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. We have an anti-virus system installed on all our PC's and therefore any files leaving us via e-mail will have been checked for known viruses. Energis Integration Services accepts no responsibility once an e-mail and any attachments leave us. If you have received this email in error please notify Energis Integration Services Communications IT department on +44 (0) 1494 476222.. ----------------------------------------------------------------------------------------------------------- VPN is sponsored by SecurityFocus.COM From rick_smith at SECURECOMPUTING.COM Thu Sep 21 16:11:48 2000 From: rick_smith at SECURECOMPUTING.COM (Rick Smith) Date: Thu, 21 Sep 2000 15:11:48 -0500 Subject: Difference Between SSL v.2 and v.3 In-Reply-To: <85256961.005373C6.00@noteswetc15.fin.equifax.com> Message-ID: <4.3.2.7.0.20000921150824.00ac62c0@mailhost.sctc.com> At 10:10 AM 9/21/00, Charles.Clayton at EQUIFAX.COM wrote: >Hello all, > >Can anyone point me to a mod list of the differences between SSL v.2 and v.3? The last I checked, you can find this information in the Appendix of the SSL v.3 protocol spec. I summarized some of this info in Section 9.4.3 of "Internet Cryptography." Rick. smith at securecomputing.com roseville, minnesota "Internet Cryptography" at http://www.visi.com/crypto/ VPN is sponsored by SecurityFocus.COM From Ian.Moran at KONNEXION.COM Thu Sep 21 13:05:03 2000 From: Ian.Moran at KONNEXION.COM (Ian Moran) Date: Thu, 21 Sep 2000 18:05:03 +0100 Subject: Fwd: TechTip: What's a VPN, Anyway? Message-ID: I wish I was - makes good sense to do so. The Belfast & Brussels sites use UUnet, the Atlanta site uses AT&T (not my choice I hasten to add) Ian > -----Original Message----- > From: Joseph S D Yao [mailto:jsdy at cospo.osis.gov] > Sent: 21 September 2000 00:30 > To: Ian Moran > Cc: VPN at SECURITYFOCUS.COM > Subject: Re: Fwd: TechTip: What's a VPN, Anyway? > > > On Wed, Sep 20, 2000 at 09:45:03PM +0100, Ian Moran wrote: > > My experience differs. I've established a VPN over internet > connections > > from our Belfast office to our Atlanta & Brussels office > and performance > > and reliability has been excellent in the 6 months this has been > > running. > > > > Ian > > Are you using the same ISP at each site, e.g., UUNet? > > -- > Joe Yao jsdy at cospo.osis.gov - > Joseph S. D. Yao > COSPO/OSIS Computer Support EMT-B > -------------------------------------------------------------- > --------- > This message is not an official statement of COSPO policies. > VPN is sponsored by SecurityFocus.COM From m_basha at AGAINTECH.COM Thu Sep 21 19:01:19 2000 From: m_basha at AGAINTECH.COM (Mohamed Mohaideen Basha) Date: Thu, 21 Sep 2000 16:01:19 -0700 Subject: What is GRE Message-ID: <002501c0241f$da8354c0$3201a8c0@again-tech> Can any one tell me what is GRE in VPN technology as I am still in learning process in VPN. -Basha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000921/0c731e8b/attachment.htm From JJones at NWNETS.COM Fri Sep 22 15:27:30 2000 From: JJones at NWNETS.COM (Jeremy Jones (BOI)) Date: Fri, 22 Sep 2000 13:27:30 -0600 Subject: What is GRE Message-ID: GRE stands for Generic Routing Encapsulation. It is used with PPTP, along w/tcp port 1723. GRE is a protocol alongside tcp, udp, etc. It is protocol number 47 (useful info when configuring NAT/Firewalls). jj -----Original Message----- From: Mohamed Mohaideen Basha [mailto:m_basha at AGAINTECH.COM] Sent: Thursday, September 21, 2000 5:01 PM To: VPN at SECURITYFOCUS.COM Subject: What is GRE Can any one tell me what is GRE in VPN technology as I am still in learning process in VPN. -Basha VPN is sponsored by SecurityFocus.COM From CBridgett at GREENWICHTECH.COM Fri Sep 22 15:32:21 2000 From: CBridgett at GREENWICHTECH.COM (Bridgett, Cynthia) Date: Fri, 22 Sep 2000 15:32:21 -0400 Subject: What is GRE Message-ID: <87ADE652B37DD311924100508B6F92ACAA2E2F@augusta.greenwichtech.com> GRE is a tunneling protocol that defines a type of encapsulation used within a tunnel across a VPN. -----Original Message----- From: Mohamed Mohaideen Basha To: VPN at SECURITYFOCUS.COM Sent: 9/21/00 7:01 PM Subject: What is GRE Can any one tell me what is GRE in VPN technology as I am still in learning process in VPN. -Basha VPN is sponsored by SecurityFocus.COM From jsdy at COSPO.OSIS.GOV Fri Sep 22 16:10:54 2000 From: jsdy at COSPO.OSIS.GOV (Joseph S D Yao) Date: Fri, 22 Sep 2000 16:10:54 -0400 Subject: What is GRE In-Reply-To: <002501c0241f$da8354c0$3201a8c0@again-tech>; from m_basha@AGAINTECH.COM on Thu, Sep 21, 2000 at 04:01:19PM -0700 References: <002501c0241f$da8354c0$3201a8c0@again-tech> Message-ID: <20000922161054.M29710@washington.cospo.osis.gov> On Thu, Sep 21, 2000 at 04:01:19PM -0700, Mohamed Mohaideen Basha wrote: > Can any one tell me what is GRE in VPN technology as I am still in learning process in VPN. > > -Basha See RFC 1701. 1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT=15460 bytes) (Status: INFORMATIONAL) It is a very simple type of tunneling that encapsulates packets within larger packets, but does not encrypt them. -- Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao COSPO/OSIS Computer Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies. VPN is sponsored by SecurityFocus.COM From evyncke at CISCO.COM Fri Sep 22 16:10:54 2000 From: evyncke at CISCO.COM (Eric Vyncke) Date: Fri, 22 Sep 2000 22:10:54 +0200 Subject: What is GRE In-Reply-To: <002501c0241f$da8354c0$3201a8c0@again-tech> Message-ID: <4.2.0.58.20000922220519.00b8f7a0@brussels.cisco.com> GRE= Generic Routing Encapsulation, see RFC 1701 It is basically encapsulation of any protocol (IP, AppleTalk, DECnet, IPX, ...) in an IP packet. This is a network service and not a security service as there is neither confidentiality nor authentication. In combination with IPSec in transport mode, GRE is a very powerful and secure technology used in large VPN (>500 nodes) Just my still falling 0.01 EUR -eric At 16:01 21/09/2000 -0700, Mohamed Mohaideen Basha wrote: >Can any one tell me what is GRE in VPN technology as I am still in learning process in VPN. > >-Basha Eric Vyncke Senior Consulting Engineer Cisco Systems EMEA Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke at cisco.com Mobile: +32-75-312.458 PGP Key available on request -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.shmoo.com/pipermail/vpn/attachments/20000922/ac622583/attachment.htm From jvaughan at MAAD.COM Fri Sep 22 20:07:41 2000 From: jvaughan at MAAD.COM (John Vaughan) Date: Fri, 22 Sep 2000 18:07:41 -0600 Subject: FW: Question Message-ID: -----Original Message----- From: Tina Bird [mailto:tbird at precision-guesswork.com] Sent: Friday, September 22, 2000 4:19 PM To: John Vaughan Subject: Re: Question please forward this to vpn at securityfocus.com thanks -- tbird On Fri, 22 Sep 2000, John Vaughan wrote: > Date: Fri, 22 Sep 2000 17:47:44 -0600 > From: John Vaughan > To: tbird at precision-guesswork.com > Subject: Question > > Hello Tina > > My name is John Vaughan and I work for Micro Analysis and Design in Boulder, > Co. Ran across your website (very interesting) while researching VPN's. We > are interested in setting up VPN for off-site dial up users. The flow would > be from: > > Windows box -> ISP -> Linux Router/Firewall -> Windows NT server. > > Do you know of any good resources that explain this particular scenario. > > Any help would be appreciated > > thanks > > John Vaughan > Micro Analysis & Design, Inc. > 4900 Pearl East Circle, Suite 201 E > Boulder, CO 80301 > 303 442-6947 > 303 442-8274 fax > mailto:jvaughan at maad.com > > VPN: http://kubarb.phsx.ukans.edu/~tbird/vpn.html life: http://kubarb.phsx.ukans.edu/~tbird work: http://www.counterpane.com VPN is sponsored by SecurityFocus.COM From ddessi at ICNT.NET Fri Sep 22 20:32:48 2000 From: ddessi at ICNT.NET (Danilo Dessi) Date: Fri, 22 Sep 2000 20:32:48 -0400 Subject: Remote Control/Access Software and VPN's Message-ID: We have a VPN utilizing IPSEC. However, we cannot establish any remote PCAnywhere session with any resource on the LAN by utilizing a VPN connection. Is this because PCAnywhere cannot work in an encrypted tunnel? Can someone explain the reason for this in lay man's terms? Thank you to everyone. Dan VPN is sponsored by SecurityFocus.COM From kyoung at V-ONE.COM Fri Sep 22 21:26:57 2000 From: kyoung at V-ONE.COM (Keith Young) Date: Fri, 22 Sep 2000 21:26:57 -0400 Subject: Remote Control/Access Software and VPN's References: Message-ID: <39CC06E1.93376DE9@v-one.com> Danilo Dessi wrote: > > We have a VPN utilizing IPSEC. However, we cannot establish any > remote PCAnywhere session with any resource on the LAN by utilizing a > VPN connection. Is this because PCAnywhere cannot work in an > encrypted tunnel? Can someone explain the reason for this in lay > man's terms? PCAnywhere uses UDP broadcasts in order to find a machine and determine if it is busy or not. You may need to turn UDP off. We have a FAQ which explains how to do this with PCAnywhere 8.x. Ignore the sections related to our product: http://www.v-one.com/techsupport/applications.html#6 -- --Keith Young -Director of Customer Care/Support, V-ONE Corp. -kyoung at v-one.com VPN is sponsored by SecurityFocus.COM From sandy at STORM.CA Fri Sep 22 21:32:17 2000 From: sandy at STORM.CA (Sandy Harris) Date: Fri, 22 Sep 2000 21:32:17 -0400 Subject: FW: Question References: Message-ID: <39CC0821.F676D8DB@storm.ca> John Vaughan wrote: > > ... while researching VPN's. > We > > are interested in setting up VPN for off-site dial up users. The flow > would > > be from: > > > > Windows box -> ISP -> Linux Router/Firewall -> Windows NT server. > > > > Do you know of any good resources that explain this particular scenario. > > > > Any help would be appreciated > > > > thanks Linux IPSEC software: www.freeswan.org All the docs are online. User-written HowTo material covering FreeS/WAN-to-Windows interoperation: http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html http://jixen.tripod.com/ VPN is sponsored by SecurityFocus.COM From LISTSERV at LISTS.SECURITYFOCUS.COM Mon Sep 25 09:00:53 2000 From: LISTSERV at LISTS.SECURITYFOCUS.COM (L-Soft list server at SecurityFocus.com (1.8d)) Date: Mon, 25 Sep 2000 06:00:53 -0700 Subject: Expiration of your subscription to the VPN list Message-ID: <20000925130053.21C0A1EF16@lists.securityfocus.com> Mon, 25 Sep 2000 06:00:53 Your subscription to the VPN list has expired and you have failed to confirm it in the 14 day delay that you had been granted. You have therefore been automatically removed from the list. You can re-subscribe to the list, if you want to, by sending the following command to LISTSERV at LISTS.SECURITYFOCUS.COM: SUBscribe VPN