RE: Routing problem in IPv4/IPSec VPN environment
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html Essentially, once the gif tunnel has been established you just need to add an additional route for the specific gif interface from each server to the other's remote subnet using the external IP of the remote subnet as the gateway. I also found that "gateway_enable" sysctl option was be turned on for the packet traversal from behind a natted server. Hope this helps T -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James P. Howard, II Sent: Tuesday, June 29, 2004 12:57 PM To: [EMAIL PROTECTED] Subject: Routing problem in IPv4/IPSec VPN environment As a personal favor, I am building a VPN for a small business. I have chosen FreeBSD for this due to my greater familiarity. The project will consist of linking four sites, each with a FreeBSD system providing DHCP, NAT, and VPN services. I have built DHCP and NAT servers before, but the IPSec and VPN is new to me. Right now, the first two systems are nearly complete. The two machines are named goldengate and waltwhitman. Here's the IP config, currently: goldengate: external 192.168.1.101 internal 10.1.1.1 waltwhitman: external 192.168.1.102 internal 10.1.2.1 The external interfaces are in the reserved space because testing is taking place behind a cable/DSL router providing NAT services. The output of "gifconfig -a; ifconfig -a; netstat -rn" for each will be provided at the end of this message. IPSec, with Racoon, is properly exchanging keys. From goldengate, I can ping 10.1.2.1 and from waltwhitman I can ping 10.1.1.1. If a Windows computer is connected behind either system, they receive an IP (10.1.x.254, where x is the network number). The problem is, if behind the 10.1.2.1 firewall, I cannot ping 10.1.1.1 and vice-versa. I assume, at this point, this is some type of routing issue and not a problem with IPSec. This seems to be confirmed by the fact tracerouting to the local internal interface goes through the *other* internal interface first: waltwhitman$ ifconfig bge1; traceroute 10.1.2.1 bge1: flags=8843 mtu 1500 options=3 inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255 inet6 fe80::209:5bff:fe60:e508%bge1 prefixlen 64 scopeid 0x2 ether 00:09:5b:60:e5:08 media: Ethernet autoselect (10baseT/UTP ) status: active traceroute to 10.1.2.1 (10.1.2.1), 64 hops max, 44 byte packets 1 10.1.1.1 (10.1.1.1) 0.848 ms 0.736 ms 0.783 ms 2 10.1.2.1 (10.1.2.1) 1.173 ms 1.262 ms 1.247 ms The other machine behaves identically, except the numbers are reversed. At this point, I have reached the limits of my knowledge. Any help would be appreciated. Thank you, James Notes on the output: IPv6 info removed from netstat output. There is a third interface in WALTWHITMAN which may break off to a DMZ in the future. No descision has been made and won't be for some time. The interface was given the IP 172.16.1.1. GOLDENGATE: goldengate$ gifconfig -a; ifconfig -a; netstat -rn gif0: flags=8051 mtu 1280 inet 10.1.1.1 --> 10.1.2.1 netmask 0x inet6 fe80::209:5bff:fe62:714e%gif0 prefixlen 64 physical address inet 192.168.1.101 --> 192.168.1.102 bge0: flags=8843 mtu 1500 options=3 inet 10.1.1.1 netmask 0xff00 broadcast 10.1.1.255 inet6 fe80::209:5bff:fe62:714e%bge0 prefixlen 64 scopeid 0x1 ether 00:09:5b:62:71:4e media: Ethernet autoselect (100baseTX ) status: active xl0: flags=8843 mtu 1500 options=1 inet6 fe80::2b0:d0ff:fe23:5b8d%xl0 prefixlen 64 scopeid 0x2 inet 192.168.1.101 netmask 0xff00 broadcast 192.168.1.255 ether 00:b0:d0:23:5b:8d media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 faith0: flags=8002 mtu 1500 gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.101 --> 192.168.1.102 inet 10.1.1.1 --> 10.1.2.1 netmask 0x inet6 fe80::209:5bff:fe62:714e%gif0 prefixlen 64 scopeid 0x6 Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.1.1UGSc3 6082xl0 10.1.1/24 link#1 UC 20 bge0 10.1.1.1 00:09:5b:62:71:4e UHLW0 306lo0 10.1.1.254 link#1 UHLW214933 bge0 10.1.2/24 10.1.2.0 UGSc015578xl0 10.1.2.1 10.1.1.1 UH 0 2060 gif0 127.0.0.1 127.0.0.1 UH 1 48lo0 192.168.1 link#2 UC 30xl0 192.168.1.100:0c:41:7f:8a:6e UHLW42xl0 1042 192.168.1.100 00:30:65:2e:ae:f7 UHLW0
Re: Routing problem in IPv4/IPSec VPN environment
- Original Message - From: "James P. Howard, II" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 29, 2004 2:57 PM Subject: Routing problem in IPv4/IPSec VPN environment > As a personal favor, I am building a VPN for a small business. I > have chosen FreeBSD for this due to my greater familiarity. The > project will consist of linking four sites, each with a FreeBSD > system providing DHCP, NAT, and VPN services. I have built DHCP and > NAT servers before, but the IPSec and VPN is new to me. > > Right now, the first two systems are nearly complete. The two > machines are named goldengate and waltwhitman. Here's the IP > config, currently: > > goldengate: external 192.168.1.101 internal 10.1.1.1 > waltwhitman: external 192.168.1.102 internal 10.1.2.1 > > The external interfaces are in the reserved space because testing is > taking place behind a cable/DSL router providing NAT services. The > output of "gifconfig -a; ifconfig -a; netstat -rn" for each will be > provided at the end of this message. > > IPSec, with Racoon, is properly exchanging keys. From goldengate, I > can ping 10.1.2.1 and from waltwhitman I can ping 10.1.1.1. > > If a Windows computer is connected behind either system, they > receive an IP (10.1.x.254, where x is the network number). > > The problem is, if behind the 10.1.2.1 firewall, I cannot ping > 10.1.1.1 and vice-versa. I assume, at this point, this is some type > of routing issue and not a problem with IPSec. This seems to be > confirmed by the fact tracerouting to the local internal interface > goes through the *other* internal interface first: Not to be disrespectful, but did you do what I've done in the past and forget to enable forwarding so the systems can route traffic? [EMAIL PROTECTED]/>sysctl -a |grep forward net.inet.ip.forwarding: 1 If not, make sure that gateway_enable="YES" in rc.conf and reboot, or sysctl net.inet.ip.forwarding=1 from command line to enable it without a reboot. -- Micheal Patterson TSG Network Administration 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
