Hi An-Cheng,
I see.
Looking forward to alpha2(if there is something new about remote-access).
Thanks,
Adrian
An-Cheng Huang wrote:
> Hi Adrian,
>
> You're right that xl2tpd fixed both issues. However, the email you mentioned
> said the fixes were for "openswan's new KLIPS code". The manpage for
h its own cli with command completion etc.
>
> -paul
>
> Adrian F. Dimcev wrote:
>
>> Hi An-Cheng,
>> Yesterday I was reading the xelerance xl2tpd change log:
>> http://www.xelerance.com/software/xl2tpd/CHANGES
>> And I was under the impression that both i
Hi An-Cheng,
Yesterday I was reading the xelerance xl2tpd change log:
http://www.xelerance.com/software/xl2tpd/CHANGES
And I was under the impression that both issues you've mentioned are fixed.
v1.1.05 references these changes.
In this mail, Paul Wouters, also mentions the same things:
http://list
Hi,
Playing further with Glendale and Remote Access.
I've setup L2TP/IPsec with certificates(IKE authentication).
Build a quick CA with OpenSSL and issue some certificates(public key
1024 bits). One to Glendale and two to clients(Windows clients).
VPN_Clients---NAT_Device---Glendale---Internal Net
nging the global IPsec configuration, which, again,
> may change the site-to-site behavior. The current approach is to let
> the user configure it (using "outside-nexthop"). I'll investigate
> further to see if we can simplify this.
>
> Thanks for playing with th
Hi,
I was messing with Glendale today and with the new remote access features.
I've setup a simple lab test:
VPNClient(192.168.22.2)---Vyatta(doing NAT)-Internal
Network(192.168.10.0/24)
First with PPTP: 1,2,3 and it was up and running.
Cool!
Moving to L2TP/IPsec: 1,2 and I've nailed it. S
Josh wrote:
>Adrian,
>Once again, thank you for your invaluable input! I will begin working on
your below suggestions, as this does make a lot of sense. I also need to
peruse the >Vyatta_CommandRef_VC3_v02.pdf more thoroughly to "take the
pieces from there and complete [the] puzzle" . But I first
Hi Todd,
Whatever you need. It's all about that. To know what you need.
Yep, you've got those static NAT mappings so actually when you're
hitting Vyatta traffic gets redirected.
But some of those mappings apply only to TCP traffic, so the "rest" will
go to Vyatta itself. Here that "Local" instance
>Just for sanity's sake, can someone chime in and confirm if this appears to be
>an appropriate configuration? >Any suggestions are welcome!
Don't know if you've noticed or if this was your intention but are you
aware that your Vyatta is fully accessible from the Internet(or at least
your posted
Hi Todd,
If you define a firewall instance "wan2lan" as "OUT" on eth0 then the
implicit deny you've mentioned only applies to eth0 and only to packets
exiting interface eth0 that are not matched by any of your firewall
rules from that instance.
Per interface you can define three firewall instances:
Ahh,
About Vyatta's manuals, I would say they are pretty good.
For example Vyatta_CommandRef_VC3_v02.pdf contains all I have said, you
can take the pieces from there and complete your puzzle(your scenario).
Regarding the security of those SOHO devices, you are much more secure
with Vyatta.
Adrian
Hi,
I have written some articles about Vyatta:
How to Create a VPN Site-to-Site IPsec Tunnel Mode Connection Between a
Vyatta OFR and an ISA 2006 Firewall(creating the site-to-site on Vyatta,
setup a basic firewall on Vyatta in relation with the site-to-site VPN,
adding the NAT rule stuff like
Hi Josh,
Guess what, all that info and much more is documented now here(Community
Documentation):
http://www.vyatta.com/twiki/bin/view/Community/CommunityDocumentation
More exactly within the article How to Create a VPN Site-to-Site IPsec
Tunnel Mode Connection Between a Vyatta OFR and an ISA 2006
Hi Josh,
There is no firewall by default on Vyatta.
Your firewall rule does not prevent packets from "external" to your
Vyatta itself.
You can apply the firewall instance as in, out and local per interface.
You have used in, meaning that packets entering that interface will be
filtered by the firew
>Stig wrote:
>I think the reason for the immediate re-establishment is the "auto=start"
>value in /etc/ipsec.conf. If you want to experiment you could try logging
>in as root and edit /etc/ipsec.conf and change "auto=start" to "auto=add".
>Then go back into xorpsh and do a "clear vpn ipsec-process"
>Stig wrote
>I'm not sure if this will do what you want, but you might try setting the
>lifetime of the ipsec key with:
>[EMAIL PROTECTED] set vpn ipsec esp-group foo lifetime
>Possible completions:
>[30..86400] Set lifetime in seconds
Hi Stig,
Thank you for your reply.
No, I wasn't talking about
>>Stig wrote
>>You can define multiple tunnels under the same peer to accomplish that.
>Philippe wrote
>Yes but it is not an optimal solution in term of scalibility.
I would agree with Philippe.
If we have multiple local and remote subnets it becomes a little
painful.
With Cisco's crypto_acl that'
Hi,
Can we set on Vyatta an IPsec SA idle timer?
For example the other side of the tunnel has set this timer to 5 min.
If within 5 min no traffic is passing through the tunnel, the IPsec SA
is deleted.
Note that the other end does not support DPD.
>From what I can see, the other side is deleting
were getting through Vyatta.Thanks!Adrian
Original Message
Subject: Re: [Vyatta-users] Vyatta Stateful Firewall Issue
From: Robyn Orosz <[EMAIL PROTECTED]>
Date: Wed, November 14, 2007 10:57 pm
To: "Adrian F. Dimcev" <[EMAIL PROTECTED]>
Cc: vyatta-users@ma
Hi Dave and Robyn,
Robyn,
Thanks for the NAT exclusion solution.
Dave,
Once that article will be finished I will add a link there.
Things look good regarding the tunnel between Vyatta and ISA.
Except that it seems to be one ISAKMP Informational Exchanges after the
Quick Mode messages sent by Vyat
ace: "eth0"
source {
network: "192.168.40.0/24"
}
destination {
network: "!192.168.10.0/24"
}
outside-address {
address: 192.168.22.225
}
}
A weird thing:
When I specify a
I've been testing with vc2.2 too.
Same problem regarding the ACK segment.
Everything else seems to work just fine(is blocking other TCP segments
with different flag combinations).
However the "lonely" ACK segment is passing free through Vyatta.
Looks like a bug to me.
Hi,
I'm putting an article on my website about how to create a site-to-site
connection between Vyatta and ISA 2006.
There is a little problem with the NAT scenario when I'm NAT-ing from
Internal to External. If the remote site contains multiple subnets which
are not contiguos so they can be summar
Hi,I've been playing a little bit with Vyatta's firewall and I've noticed a litlle problem.As the documetation says Vyatta offers stateful inspection.As my test shown it is so.However I can always pass an ACK segment which is not a part of any existing connection.I'm usually using namp or hping to
Hi guys,In Vyatta_ConfigGuide_VC2.2_v01.pdf, page 229, Table 14-3 there is a serious error regarding Diffie-Hellman group 5:"5 Diffie-Hellman group 5 is a 1536-bit modular exponentiation(MODP) group. This is a 1024-bit group with a key strengthapproximately equivalent to symmetric keys of length 12
25 matches
Mail list logo
