summaryrefslogtreecommitdiff
path: root/sbin/brconfig
diff options
context:
space:
mode:
authorAngelos D. Keromytis <angelos@cvs.openbsd.org>2000-12-31 00:08:15 +0000
committerAngelos D. Keromytis <angelos@cvs.openbsd.org>2000-12-31 00:08:15 +0000
commitc1bbe47ce1776ebff04a2257bd3527a07778881e (patch)
tree615b499d1c638c3066b6d53efc87f3beb58dab99 /sbin/brconfig
parent88129295b095c5f4d3805fc730b27300fd797b15 (diff)
Update example and text.
Diffstat (limited to 'sbin/brconfig')
-rw-r--r--sbin/brconfig/brconfig.872
1 files changed, 39 insertions, 33 deletions
diff --git a/sbin/brconfig/brconfig.8 b/sbin/brconfig/brconfig.8
index 4019edb0270..4babe79f825 100644
--- a/sbin/brconfig/brconfig.8
+++ b/sbin/brconfig/brconfig.8
@@ -1,4 +1,4 @@
-.\" $OpenBSD: brconfig.8,v 1.20 2000/12/28 03:40:20 jason Exp $
+.\" $OpenBSD: brconfig.8,v 1.21 2000/12/31 00:08:14 angelos Exp $
.\"
.\" Copyright (c) 1999, 2000 Jason L. Wright (jason@thought.net)
.\" All rights reserved.
@@ -55,7 +55,7 @@ utility retrieves kernel state of bridge interfaces and allows
user control of these bridges.
Bridge devices create a logical link between two or more Ethernet interfaces
or encapsulation interfaces (see
-.Xr enc 4 ),
+.Xr gif 4 ),
which will selectively forward frames from each interface on the bridge
to every other interface on the bridge.
This can be used to isolate traffic between sets of machines on the same
@@ -252,22 +252,31 @@ fxp0 to 0:1:2:3:4:5.
All other traffic trying to go into and be sent from fxp0 will be blocked.
.El
.Sh "IPSEC BRIDGE"
-The bridge can also be used to tunnel ethernet frames through
-.Xr ipsec 4
-encapsulated interface. In addition to adding Ethernet interfaces,
+The bridge can also be used to tunnel ethernet frames over IPv4 or
+IPv6 by using the
+.Xr gif 4
+interface. In addition to adding Ethernet interfaces,
one or more
-.Xr enc 4 ,
+.Xr gif 4 ,
interfaces are added as members of the bridge. Ethernet frames sent
through the
-.Xr enc 4
-interfaces are encrypted and/or authenticated and encapsulated in
+.Xr gif 4
+interfaces are encapsulated inside
.Xr ip 4
datagrams and sent across the network to another bridge, which
-decapsulates the datagram, decrypts and verifies the payload, and
-then processes the resulting Ethernet frame as if it had originated
-on a normal Ethernet interface. This effectively allows a layer-2 network
-to be extended from one point to another, possibly through the Internet,
-without the traffic passing through in the clear.
+decapsulates the datagram and then processes the resulting Ethernet
+frame as if it had originated on a normal Ethernet interface. This
+effectively allows a layer-2 network to be extended from one point to
+another, possibly through the Internet. This mechanism may be used in
+conjunction with IPsec, by specifying the appropriate IPsec flows
+between the two bridges. To only protect the bridge traffic between
+the two bridges, the transport protocol 97 (etherip) selector may be
+used in
+.Xr ipsecadm 8
+or
+.Xr isakmpd 8 .
+Otherwise, the ethernet frames will be sent in the clear between the
+two bridges.
.Pp
For example, given two physically seperate Ethernet networks, the bridge can
be used as follows to make them appear as the same local area network.
@@ -280,7 +289,13 @@ network1 and network2.
Add the encapsulation interface and internal ethernet interface to bridge
interface:
.Bd -literal
-# brconfig bridge0 add enc1 add fxp1
+# brconfig bridge0 add gif0 add fxp1
+.Ed
+.Pp
+Configure the gif0 interface:
+.Bd -literal
+(on bridge 1) # ifconfig gif0 giftunnel 1.2.3.4 4.3.2.1
+(on bridge 2) # ifconfig gif0 giftunnel 4.3.2.1 1.2.3.4
.Ed
.Pp
Create Security Associations (SAs) between the external IP address of each
@@ -298,28 +313,19 @@ bridge:
Setup ingress flows so that traffic is allowed between the two bridges
for the above associations:
.Bd -literal
-(on bridge1) # ipsecadm flow -dst 1.2.3.4 -in \e\
- -transport etherip -require \e\
- -addr 4.3.2.1 255.255.255.255 1.2.3.4 255.255.255.255
-(on bridge2) # ipsecadm flow -dst 4.3.2.1 -in \e\
+(on bridge1) # ipsecadm flow -dst 4.3.2.1 -out \e\
-transport etherip -require \e\
-addr 1.2.3.4 255.255.255.255 4.3.2.1 255.255.255.255
-.Ed
-.Pp
-Add the source and destination SAs to the encapsulation interface, and
-start allowing traffic on the interface:
-.Bd -literal
-(on bridge1) # ifconfig enc1 dstsa 4.3.2.1/4242/esp
-(on bridge1) # ifconfig enc1 srcsa 1.2.3.4/4243/esp
-(on bridge2) # ifconfig enc1 dstsa 1.2.3.4/4243/esp
-(on bridge2) # ifconfig enc1 srcsa 4.3.2.1/4242/esp
+(on bridge2) # ipsecadm flow -dst 1.2.3.4 -out \e\
+ -transport etherip -require \e\
+ -addr 4.3.2.1 255.255.255.255 1.2.3.4 255.255.255.255
.Ed
.Pp
Bring up the internal interface (if not already up) and encapsulation
interface:
.Bd -literal
# ifconfig fxp1 up
-# ifconfig enc1 up
+# ifconfig gif0 up
.Ed
.Pp
Finally, bring the bridge interface up and allow it to start processing
@@ -347,11 +353,11 @@ to
.Nm brconfig
STP can be enabled or disabled on each port.
STP will not work on
-.Xr enc 4
+.Xr gif 4
members because they lack a hardware MAC address.
.Sh SEE ALSO
.Xr bridge 4 ,
-.Xr enc 4 ,
+.Xr gif 4 ,
.Xr ip 4 ,
.Xr ipsec 4 ,
.Xr bridgename.if 5 ,
@@ -381,8 +387,8 @@ which receives its own transmissions (this renders the address learning
cache useless).
Most other chipsets work fine though.
.Pp
-The SAs used on the
-.Xr enc 4
-interfaces should not cause transmission over one of the "real" ethernet
+The packets generated by the
+.Xr gif 4
+interfaces must not cause transmission over one of the "real" ethernet
member interfaces of the bridge, or else an infinite packet forwarding loop
will occur.