[leaf-user] [ leaf-Support Requests-677595 ] Problems communicating via VPN
Support Requests item #677595, was opened at 2003-01-30 09:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=677595group_id=13751 Category: packages Group: None Status: Closed Priority: 5 Submitted By: Bob Dushok (bdushok) Assigned to: Mike Noyes (mhnoyes) Summary: Problems communicating via VPN Initial Comment: I'm attempting to configure a subnet to subnet VPN between two Bering uclibc v1.02 firewalls and am having difficulty. The VPN appears to be coming up, but no traffic seems to pass through it. My systems are setup as follows: workstation1 - ip 10.12.0.2 | bering gw - internal 10.12.0.1 - external 66.202.70.89 | (internet) | bering gw - internal 10.1.2.200 - external 199.224.108.200 | workstation 2 - ip 10.1.1.1 The external IPs are statically assigned, I'm not using DHCP. When entering ipsec auto --up vpn I receive the following: 104 vpn #8: STATE_MAIN_I1: initiate 106 vpn #8: STATE_MAIN_I2: sent MI2, expecting MR2 108 vpn #8: STATE_MAIN_I3: sent MI3, expecting MR3 004 vpn #8: STATE_MAIN_I4: ISAKMP SA established 112 vpn #9: STATE_QUICK_I1: initiate 004 vpn #9: STATE_QUICK_I2: sent QI2, IPsec SA established The output of ipsec look is: 000 interface ipsec0/eth0 199.224.108.200 000 000 vpn: 10.1.0.0/16===199.224.108.200---199.224.108.34...66.202.70.88---66.202.70.89===10.12.0.0/16 000 vpn: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 vpn: policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth0; erouted 000 vpn: newest ISAKMP SA: #3; newest IPsec SA: #2; eroute owner: #2 000 000 #3: vpn STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 998s; newest ISAKMP 000 #2: vpn STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 23043s; newest IPSEC; eroute owner 000 #2: vpn [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It appears the VPN is up, but 10.12.0.2 can't ping 10.1.1.1 and vice versa. My conf looks as follows: config setup interfaces=%defaultroute klipsdebug=none plutodebug=all plutoload=%search plutostart=%search conn %default type=tunnel keyexchange=ike keylife=8h keyingtries=0 authby=rsasig disablearrivalcheck=no pfs=yes conn vpn left=199.224.108.200 leftsubnet=10.1.0.0/16 leftnexthop=199.224.108.34 leftfirewall=yes right=66.202.70.89 rightsubnet=10.12.0.0/16 rightnexthop=66.202.70.88 rightfirewall=yes auto=add leftrsasigkey=(omitted) rightrsasigkey=(ommitted) I've added a zone for the VPN and have a rule similar to the following added to the Shorewall rules: vpnnet localnetACCEPT localnet vpnnet ACCEPT (sorry I don't have the exact text of these rules) hosts.allow does include an ALL: entry denoting the private network on the other end of the VPN. Do I need to perform any masquerading on the IPSEC0 interface for the nets to communicate properly? As I was searching the mailing list, I noticed conversations which mentioned an ipsec masquerade kernel driver. I can't seem to locate any info on this for Bering/uclibc. Am I missing something important? The only modules I'm loading for masquerading came with the Bering release (ip_conntrack_ftp, ip_conntrack_irc, ip_nat_ftp, and ip_nat_irc). When shorewall starts it prints a warning indicating the zone I've created for my VPN is empty. I've defined the zone by including the following in the zones file: vpnzone ipsec0 Does this warning indicate a problem? Any suggestions would be appreciated. TIA Bob -- Comment By: Bob Dushok (bdushok) Date: 2003-01-31 18:26 Message: Logged In: YES user_id=694924 Based on the most recent comment on this support request, it is our understanding that this matter has been addressed. Should you require further assistance from LEAF project members, please submit a new support request. Thank you, leaf-project.org support -- Comment By: Bob Dushok (bdushok) Date: 2003-01-31 18:26 Message: Logged In: YES user_id=694924 Lynn, Thanks. Why I was pinging the gateway is a mystery, I know not to do that :) I accidentally submitted this support request twice (long story). In the first posting of this Tom noticed I had omitted my ipsec interface from the Shorwall zones file. That problem was preventing my VPN from running. All is well now. Thanks for the reply. BTW, your basic IPSEC documentation is excellent and helped greatly! Bob -- Comment By: Lynn Avants (guitarlynn) Date: 2003-01-30 20:02 Message: Logged In: YES user_id=176069 OK, basic IPSec stuff now. You can _not_ ping either of the gateways with
[leaf-user] [ leaf-Support Requests-677595 ] Problems communicating via VPN
Support Requests item #677595, was opened at 2003-01-30 12:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=677595group_id=13751 Category: packages Group: None Status: Open Priority: 5 Submitted By: Bob Dushok (bdushok) Assigned to: Mike Noyes (mhnoyes) Summary: Problems communicating via VPN Initial Comment: I'm attempting to configure a subnet to subnet VPN between two Bering uclibc v1.02 firewalls and am having difficulty. The VPN appears to be coming up, but no traffic seems to pass through it. My systems are setup as follows: workstation1 - ip 10.12.0.2 | bering gw - internal 10.12.0.1 - external 66.202.70.89 | (internet) | bering gw - internal 10.1.2.200 - external 199.224.108.200 | workstation 2 - ip 10.1.1.1 The external IPs are statically assigned, I'm not using DHCP. When entering ipsec auto --up vpn I receive the following: 104 vpn #8: STATE_MAIN_I1: initiate 106 vpn #8: STATE_MAIN_I2: sent MI2, expecting MR2 108 vpn #8: STATE_MAIN_I3: sent MI3, expecting MR3 004 vpn #8: STATE_MAIN_I4: ISAKMP SA established 112 vpn #9: STATE_QUICK_I1: initiate 004 vpn #9: STATE_QUICK_I2: sent QI2, IPsec SA established The output of ipsec look is: 000 interface ipsec0/eth0 199.224.108.200 000 000 vpn: 10.1.0.0/16===199.224.108.200---199.224.108.34...66.202.70.88---66.202.70.89===10.12.0.0/16 000 vpn: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 vpn: policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth0; erouted 000 vpn: newest ISAKMP SA: #3; newest IPsec SA: #2; eroute owner: #2 000 000 #3: vpn STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 998s; newest ISAKMP 000 #2: vpn STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 23043s; newest IPSEC; eroute owner 000 #2: vpn [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It appears the VPN is up, but 10.12.0.2 can't ping 10.1.1.1 and vice versa. My conf looks as follows: config setup interfaces=%defaultroute klipsdebug=none plutodebug=all plutoload=%search plutostart=%search conn %default type=tunnel keyexchange=ike keylife=8h keyingtries=0 authby=rsasig disablearrivalcheck=no pfs=yes conn vpn left=199.224.108.200 leftsubnet=10.1.0.0/16 leftnexthop=199.224.108.34 leftfirewall=yes right=66.202.70.89 rightsubnet=10.12.0.0/16 rightnexthop=66.202.70.88 rightfirewall=yes auto=add leftrsasigkey=(omitted) rightrsasigkey=(ommitted) I've added a zone for the VPN and have a rule similar to the following added to the Shorewall rules: vpnnet localnetACCEPT localnet vpnnet ACCEPT (sorry I don't have the exact text of these rules) hosts.allow does include an ALL: entry denoting the private network on the other end of the VPN. Do I need to perform any masquerading on the IPSEC0 interface for the nets to communicate properly? As I was searching the mailing list, I noticed conversations which mentioned an ipsec masquerade kernel driver. I can't seem to locate any info on this for Bering/uclibc. Am I missing something important? The only modules I'm loading for masquerading came with the Bering release (ip_conntrack_ftp, ip_conntrack_irc, ip_nat_ftp, and ip_nat_irc). When shorewall starts it prints a warning indicating the zone I've created for my VPN is empty. I've defined the zone by including the following in the zones file: vpnzone ipsec0 Does this warning indicate a problem? Any suggestions would be appreciated. TIA Bob -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=677595group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] [ leaf-Support Requests-677595 ] Problems communicating via VPN
Support Requests item #677595, was opened at 2003-01-30 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=677595group_id=13751 Category: packages Group: None Status: Open Priority: 5 Submitted By: Bob Dushok (bdushok) Assigned to: Mike Noyes (mhnoyes) Summary: Problems communicating via VPN Initial Comment: I'm attempting to configure a subnet to subnet VPN between two Bering uclibc v1.02 firewalls and am having difficulty. The VPN appears to be coming up, but no traffic seems to pass through it. My systems are setup as follows: workstation1 - ip 10.12.0.2 | bering gw - internal 10.12.0.1 - external 66.202.70.89 | (internet) | bering gw - internal 10.1.2.200 - external 199.224.108.200 | workstation 2 - ip 10.1.1.1 The external IPs are statically assigned, I'm not using DHCP. When entering ipsec auto --up vpn I receive the following: 104 vpn #8: STATE_MAIN_I1: initiate 106 vpn #8: STATE_MAIN_I2: sent MI2, expecting MR2 108 vpn #8: STATE_MAIN_I3: sent MI3, expecting MR3 004 vpn #8: STATE_MAIN_I4: ISAKMP SA established 112 vpn #9: STATE_QUICK_I1: initiate 004 vpn #9: STATE_QUICK_I2: sent QI2, IPsec SA established The output of ipsec look is: 000 interface ipsec0/eth0 199.224.108.200 000 000 vpn: 10.1.0.0/16===199.224.108.200---199.224.108.34...66.202.70.88---66.202.70.89===10.12.0.0/16 000 vpn: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 vpn: policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth0; erouted 000 vpn: newest ISAKMP SA: #3; newest IPsec SA: #2; eroute owner: #2 000 000 #3: vpn STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 998s; newest ISAKMP 000 #2: vpn STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 23043s; newest IPSEC; eroute owner 000 #2: vpn [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It appears the VPN is up, but 10.12.0.2 can't ping 10.1.1.1 and vice versa. My conf looks as follows: config setup interfaces=%defaultroute klipsdebug=none plutodebug=all plutoload=%search plutostart=%search conn %default type=tunnel keyexchange=ike keylife=8h keyingtries=0 authby=rsasig disablearrivalcheck=no pfs=yes conn vpn left=199.224.108.200 leftsubnet=10.1.0.0/16 leftnexthop=199.224.108.34 leftfirewall=yes right=66.202.70.89 rightsubnet=10.12.0.0/16 rightnexthop=66.202.70.88 rightfirewall=yes auto=add leftrsasigkey=(omitted) rightrsasigkey=(ommitted) I've added a zone for the VPN and have a rule similar to the following added to the Shorewall rules: vpnnet localnetACCEPT localnet vpnnet ACCEPT (sorry I don't have the exact text of these rules) hosts.allow does include an ALL: entry denoting the private network on the other end of the VPN. Do I need to perform any masquerading on the IPSEC0 interface for the nets to communicate properly? As I was searching the mailing list, I noticed conversations which mentioned an ipsec masquerade kernel driver. I can't seem to locate any info on this for Bering/uclibc. Am I missing something important? The only modules I'm loading for masquerading came with the Bering release (ip_conntrack_ftp, ip_conntrack_irc, ip_nat_ftp, and ip_nat_irc). When shorewall starts it prints a warning indicating the zone I've created for my VPN is empty. I've defined the zone by including the following in the zones file: vpnzone ipsec0 Does this warning indicate a problem? Any suggestions would be appreciated. TIA Bob -- Comment By: Lynn Avants (guitarlynn) Date: 2003-01-30 22:02 Message: Logged In: YES user_id=176069 OK, basic IPSec stuff now. You can _not_ ping either of the gateways with IPSec with a tunnel, only machines on the VPN _behind_ the gateways. Try pinging a client on one subnet from a client on the other subnet. To ping either gateway, another link must be brought up that is a host connection as opposed to a gw-tunnel. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=677595group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
