On Thu, Jan 21, 2010 at 12:09 PM, Trevor Benson <tben...@a-1networks.com>wrote:
> Had the same issue you describe, as I have multiple ranges at my office > that I connect to from my home network. > > I started to dump traffic on both firewalls enc0 interface, and the network > traffic that works appears on both interfaces. The ICMP traffic that does > not reach the other end does not appear on either enc0 interface. I already > know about creating custom pre-shared keys if you have multiple connections > between the same networks (so if you have 2 tunnels between the same 2 > endpoints and use PSK, each tunnel will require its own key and could cause > issues similar to what your seeing). > > Home office networks: > I have 10.101.0.0/24 and 10.101.1.0/24 on my home pfsense firewall, > represented as 10.101.0.0/23. > > Main office networks: > I have my office LAN of 10.11.200.0/24. I have various networks for DMZ > (each a respective /24), LAB, and VoIP, represented by 172.16.0.0/14(covering > 172.16-172.19, and all of the additional /24's those include. > > > I can ping from 10.101.0.0/23 into the 172.16.0.0/14 networks. Traffic > can be destined into my network as well from the 172.16.0.0/14 networks. > > I cannot ping from 10.101.0.0/23 into 10.11.200.0/24 and 10.11.200.0/24cannot > reach my network. Watching the traffic on enc0 shows that neither > side actually forwards anything over the encrypted interface when these two > networks are trying to reach eachother. If i dump the lan interface i can > see the packet reaching the firewall, but it doesnt appear to leave the WAN, > or IPSEC interfaces. > > SAD and SPD were there, status showed both tunnels as active, but only one > passed traffic. Further testing showed even stranger results. I could ping > into the 172.16.0.0/14 networks, hence i could also make a voip call. BUT > when my employees tried to reach me, they got dead air, and not traffic > reach my end to initiate the SIP negotiation. So now it appeared i had > unidirectional access between the networks. Before i tested the alternate > direction i tried recreating the tunnels from scratch, still had the same > results. I decided to recreate the tunnels from scratch to test, and found > the same result. I deleted the 10.11.200.0/24 tunnels from both sides, > and traffic flows both directions now over the single tunnel. It started to > sound like IPSEC rule generation issues so i went to Firewall rules and > created matching rules to the flows, and now traffic is working normally. I > already had a any protocol, any source to any destination on any port rule > for testing. However, adding the specific rulesets seemed to resolve the > issue. > > I did not however check pfctl to see if the rules were existing already or > if they got munged somehow. I should be labbing up some systems to test > some XMLRPC issues i had in RC3, so ill see if i can get some time to test > the IPSEC multiple tunnels again and see if it exhibits the same symptoms. > > > Trevor Benson > A1 Networks | Network Engineer > dCAP- Digium Certified Asterisk Professional > LPIC-1, Network+, CNA, MCP > DID (707)703-1041 > Fax (707)703-1983 > tben...@a-1networks.com > > > > Thanks for the information Trevor. I deleted the 10.11.200.0/24 tunnels from both sides, and traffic flows both directions now over the single tunnel. It started to sound like IPSEC rule generation issues so i went to Firewall rules and created matching rules to the flows, and now traffic is working normally. Do you mean that with the 10.11.200.0/24 tunnel deleted from both ends that your 10.101.0.0/23 network can reach the 10.11.200.0/24 over the IPsec VPN to 172.16.0.0/14? Please do let me know if you find any more information with multiple tunnels. In the meantime I think I'll probably just have to live with the connection issue. The one technician at that site will just connect to a machine in my 192.168.1.0/24 network and then connect from that machine to a machine in the 192.168.50.0/24 network.
