The following reply was made to PR kern/127052; it has been noted by GNATS.
From: [EMAIL PROTECTED] (Helge Oldach)
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE
Date: Sat, 6 Sep 2008 07:43:42 +0200 (CEST)
I have
Ludovit Koren:
>is there any possibility to set the routing statically on a multi-homed
>host so, that the packet is sent back via the same interface, as it has
>came from?
ipfw(4) is your friend, for example on a box with addresses
192.168.20.31 and 172.16.164.54 with respective gateways 192.168.
Chris Cowen:
>A bit more investigation reveals that the SA is re-established but the
>SPD entries at the remote get dropped. This would explain the half duplex
>communication I am seeing with tcpdump (ping repsonses get back as far
>as the remote racoon machine and the lack of SPD means the machin
Holger Eitzenberger:
> (*) ERROR: ipsec_doi.c:440:print_ph1mismatched(): rejected dh_group:
>DB(prop#1:trns#1):Peer(prop#0:trns#0) = 1024-bit MODP group:1536-bit MODP
>group
>proposal {
>encryption_algorithm 3des;
>hash_algorithm md5;
>authenticati
Nick Slager:
>I have a newly created VPN between a 4.8 box and a Cisco VPN 3000
>Concentrator.
>
>/etc/ipsec.conf:
>
>flush;
>spdflush;
>spdadd 192.168.1.1/32 1.2.3.4/32 any -P out ipsec
>esp/tunnel/203.1.1.1-203.2.2.2/require;
>spdadd 1.2.3.4/32 192.168.1.1/32 any -P in ipsec
>esp/tunnel/203.2.2.2
Jacob S. Barrett:
>I have some questions about the ng_fec. Would it work if each interface
>was connected to a different switch?
I'd say this isn't an issue with ng_fec, but rather an architectural
point regarding EtherChannel as such.
I am not aware of any switch vendor that offers multi-chassis
All,
maybe someone can comment on the status of this alert? There have been
some comments about fixing it on freebsd-net@ but I haven't seen a CVS
log - or I just missed it.
Thanks.
Helge
Jacques A. Vidrine:
>Does anyone have time to investigate? I will try to get more
>information from iDEFE
Steve Greenshaw:
>
>spdadd 192.168.32.0/24 192.168.1.0/24 ipencap -P out ipsec
>esp/tunnel/AAA.AAA.AAA.AAA-BBB.BBB.BBB.BBB/require;
>spdadd 192.168.1.0/24 192.168.32.0/24 ipencap -P in ipsec
>esp/tunnel/BBB.BBB.BBB.BBB-AAA.AAA.AAA.AAA/require;
>
Try using "any" inst
Jamie Heckford:
>Helge Oldach wrote:
>> Jamie Heckford:
>>> /usr/sbin/setkey -c << EOF
>>> flush;
>>> spdflush;
>>> spdadd ${LOCAL_NETWORK} ${STJUST_NETWORK} any -P out ipsec
>>> esp/tunnel/${LOCAL_OUTSIDE}-${STJUST_OUTSIDE}/require;
&g
[Yes, this is an old issue, but I have been biten by it today, googled a
bit, and here's a dirty fix]
Alex Hayward wrote on Sun Nov 30 03:20:24 2003:
> On Sat, 29 Nov 2003, Crist J. Clark wrote:
> > I am having some problems with racoon(8). Everything works fine for
> > the lifetime of the initial
Eric Masson:
>I'm experimenting dynamic routing protocols in a vpn setup. Ipsec tunnel
>mode is not applicable here as selectors do not appear in system routing
>table.
I think the problem is that you need multicasts to exchange routing
updates through the tunnel. If I am not mistaken that is supp
Juan Rodriguez Hervella:
>On Thursday 11 December 2003 23:14, Michael Sierchio wrote:
>> Julian Elischer wrote:
>> >>>more likely he wants something like ng_fec or ng_one2many
>> >>
>> >>Unless performance is the reason for bonding the ether channels...
>> >>
>> >>Can't we steal the Linux code? ;-)
Marco Molteni:
>> I have a situation that has not been fully addressed by the excellent
>> documentation on getting ssh tunnels and remote X-windows display managers
>
>> (like VNC) running. And my feeble brain is too damaged by the dreaded
>lurgy
>> to make heads or tails of it.
>>
>> home mach
Jamie Heckford:
>/usr/sbin/setkey -c << EOF
>flush;
>spdflush;
>spdadd ${LOCAL_NETWORK} ${STJUST_NETWORK} any -P out ipsec
>esp/tunnel/${LOCAL_OUTSIDE}-${STJUST_OUTSIDE}/require;
>spdadd ${STJUST_NETWORK} ${LOCAL_NETWORK} any -P in ipsec
>esp/tunnel/${STJUST_OUTSIDE}-${LOCAL_OUTSIDE}/require;
>spd
Crist J. Clark:
>On Sat, Nov 15, 2003 at 07:54:40AM +0100, Oldach, Helge wrote:
>> From: Crist J. Clark [mailto:[EMAIL PROTECTED]
>> > Two different ESP end points behind many-to-one NAT connected to
>> > a single ESP end point on the other side of the NAT? I'd be very
>> > curious to get the docum
Crist J. Clark:
>> >ESP packets have this nice SPI field that one could
>> >potentially use to map the traffic between multiple machines behind
>> >NAT to a single VPN end point on the other side, but there is no
>> >practical way for the NAT box to learn the SPI of incoming packets.
>> Certainly t
Crist J. Clark:
>On Thu, Nov 13, 2003 at 12:46:24PM -0500, Vincent Goupil wrote:
>> I setup a firewall with ipfw2 and natd on freebsd 4.9 release.
>>
>> I have mapped my subnet with alias_address
>> I have mapped 4 private ip address with 4 public ip address
>>
>> Everything is working fine (web,
Drew Tomlinson:
>I have a 4.8 box serving as a gateway with two connections to the
>Internet. Is there some way to set the box up so that packets are
>routed out through the same interface from which they arrived? For
>example, if a connection is initiated on port 80 from a packet arriving
>on on
Walter Hop:
>I would like to connect two networks (home and work), so that I can set
>up my home workstations in the same subnet as the work LAN. Out of this
>/24, I would like to use a /29 at home.
>
>(attempt 2)
>
>The gif tunnel worked and the boxes can ping eachother over it, so I
>assigned pri
Eric Masson:
>> "Michael" == Michael Sierchio <[EMAIL PROTECTED]> writes:
>
> Michael> You should allow for an IP header with options and the ESP
> Michael> header, which is smaller than 1450. For SKIP I use 1366 as the
> Michael> advertised MTU, and for IPsec usually 1436, unless I need to
> M
Gokhan Eryol:
> I upgraded /usr/src from 4.7-RELEASE to 4.7-STABLE by cvs and trying
> to compile it for transparent web-caching with squid (wccp support). I
> tried the steps described in
> http://www.squid-cache.org/Doc/FAQ/FAQ-17.html as i did before.
I believe this should be mostly obsolete. G
Juan Francisco Rodriguez Hervella:
> Helge Oldach escribió:
> > I wonder whether there are plans to complete implementation of the
> > "strong ES" model as described in RFC 1122 for multihoming hosts on
> > FreeBSD. Essentially this would assure that a multihomed hos
All,
I wonder whether there are plans to complete implementation of the
"strong ES" model as described in RFC 1122 for multihoming hosts on
FreeBSD. Essentially this would assure that a multihomed host would
send and receive IP packets through the "correct" interface (that is,
the physical interfa
23 matches
Mail list logo
