Re: [pfSense Support] Routing Issue
On 09/05/2010 11:23 PM, Ron Lemon wrote: I have 2 facilities that used to be connected via an IPSec VPN Facility 1 had 2 networks 10.0.0.0/24 and 10.0.1.0/24. They are both on the same physical wire, they each have their own NIC in pfSense box. Users were either one or the other with a couple of people being dual homed on both. Now we get new facility 2 which is 10.0.2.0/24. I connected Facility 2 via an IPSec tunnel to Facility 1 and allow computers in the 10.0.1.0/24 network to talk to the machines in Facility 2's 10.0.2.0/24 network. All works great. Now we start to put through too much data for IPSec tunnel to handle so we now have a dedicated PVLan circuit from Facility 1 to Facility 2. I have added a 3^rd Nic to my firewall in Facility 1 and assigned an IP 10.0.2.253 to it. Now I can see all computers in Facility 1 from Facility 2 and vice versa. I still only want computers in facility 1 from 10.0.1.0/24 to see the 10.0.2.0/24. I do not want 10.0.0.0/24 to see any computer in the 10.0.2.0/24 network On my LAN interface I have set rule #1 to block traffic from 10.0.0.0/24 to 10.0.2.0/24 but that did nothing. On my Facility 2 interface I put a similar block rule still to no effect. With LAN interface, do you mean the interface connected to the 10.0.0.0/24 subnet or the 10.0.1.0/24 subnet ? You have to set the block rule on the interface the traffic is coming in. eg to block internet traffic from entering through the WAN interface, the rules have to be defined on the WAN interface. So to block traffic from 10.0.0.0/24 to 10.0.2.0/24 you have to add a block rule on the interface with the 10.0.0.0/24 subnet. (You may already know this but I couldn't find it in your message) Hope it helps. Regards, Hans
RE: [pfSense Support] Routing Issue
Facility 1 LAN interface is 10.0.0.0/24 OPT1 interface is 10.0.1.0/24 OPT2 interface is 10.0.2.253 Facility 2 LAN interface is 10.0.2.0/24 _ Ron Lemon Information Technology Manager, Maplewood Computing Ltd. | 800.265.3482 | www.maplewood.comhttp://www.maplewood.com This email message, and any files transmitted with it, are confidential and intended solely for the use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. [cid:image001.jpg@01CB4D25.FDDB2F80] From: Hans Maes [mailto:h...@bitnet.be] Sent: Sunday, September 05, 2010 6:02 PM To: support@pfsense.com Subject: Re: [pfSense Support] Routing Issue On 09/05/2010 11:23 PM, Ron Lemon wrote: I have 2 facilities that used to be connected via an IPSec VPN Facility 1 had 2 networks 10.0.0.0/24 and 10.0.1.0/24. They are both on the same physical wire, they each have their own NIC in pfSense box. Users were either one or the other with a couple of people being dual homed on both. Now we get new facility 2 which is 10.0.2.0/24. I connected Facility 2 via an IPSec tunnel to Facility 1 and allow computers in the 10.0.1.0/24 network to talk to the machines in Facility 2's 10.0.2.0/24 network. All works great. Now we start to put through too much data for IPSec tunnel to handle so we now have a dedicated PVLan circuit from Facility 1 to Facility 2. I have added a 3rd Nic to my firewall in Facility 1 and assigned an IP 10.0.2.253 to it. Now I can see all computers in Facility 1 from Facility 2 and vice versa. I still only want computers in facility 1 from 10.0.1.0/24 to see the 10.0.2.0/24. I do not want 10.0.0.0/24 to see any computer in the 10.0.2.0/24 network On my LAN interface I have set rule #1 to block traffic from 10.0.0.0/24 to 10.0.2.0/24 but that did nothing. On my Facility 2 interface I put a similar block rule still to no effect. With LAN interface, do you mean the interface connected to the 10.0.0.0/24 subnet or the 10.0.1.0/24 subnet ? You have to set the block rule on the interface the traffic is coming in. eg to block internet traffic from entering through the WAN interface, the rules have to be defined on the WAN interface. So to block traffic from 10.0.0.0/24 to 10.0.2.0/24 you have to add a block rule on the interface with the 10.0.0.0/24 subnet. (You may already know this but I couldn't find it in your message) Hope it helps. Regards, Hans inline: image001.jpg
RE: [pfSense Support] Routing Issue
I have the link working from Facility 2 to Facility 1 but it is erratic. From 10.0.2.0/24 I can ping 10.0.1.0/24 and am denied access to 10.0.0.0/24 I cannot get it go the other way. From 10.0.1.100 I do a tracert to 10.0.2.100. I see the path go to 10.0.1.254 (the router) and no further. _ Ron Lemon Information Technology Manager, Maplewood Computing Ltd. | 800.265.3482 | www.maplewood.comhttp://www.maplewood.com This email message, and any files transmitted with it, are confidential and intended solely for the use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. [cid:image001.jpg@01CB4D34.DC3C7960] From: Hans Maes [mailto:h...@bitnet.be] Sent: Sunday, September 05, 2010 6:02 PM To: support@pfsense.com Subject: Re: [pfSense Support] Routing Issue On 09/05/2010 11:23 PM, Ron Lemon wrote: I have 2 facilities that used to be connected via an IPSec VPN Facility 1 had 2 networks 10.0.0.0/24 and 10.0.1.0/24. They are both on the same physical wire, they each have their own NIC in pfSense box. Users were either one or the other with a couple of people being dual homed on both. Now we get new facility 2 which is 10.0.2.0/24. I connected Facility 2 via an IPSec tunnel to Facility 1 and allow computers in the 10.0.1.0/24 network to talk to the machines in Facility 2's 10.0.2.0/24 network. All works great. Now we start to put through too much data for IPSec tunnel to handle so we now have a dedicated PVLan circuit from Facility 1 to Facility 2. I have added a 3rd Nic to my firewall in Facility 1 and assigned an IP 10.0.2.253 to it. Now I can see all computers in Facility 1 from Facility 2 and vice versa. I still only want computers in facility 1 from 10.0.1.0/24 to see the 10.0.2.0/24. I do not want 10.0.0.0/24 to see any computer in the 10.0.2.0/24 network On my LAN interface I have set rule #1 to block traffic from 10.0.0.0/24 to 10.0.2.0/24 but that did nothing. On my Facility 2 interface I put a similar block rule still to no effect. With LAN interface, do you mean the interface connected to the 10.0.0.0/24 subnet or the 10.0.1.0/24 subnet ? You have to set the block rule on the interface the traffic is coming in. eg to block internet traffic from entering through the WAN interface, the rules have to be defined on the WAN interface. So to block traffic from 10.0.0.0/24 to 10.0.2.0/24 you have to add a block rule on the interface with the 10.0.0.0/24 subnet. (You may already know this but I couldn't find it in your message) Hope it helps. Regards, Hans inline: image001.jpg
Re: [pfSense Support] Routing issue between LAN and OPT1 when IPSEC enabled
On Thu, Jan 21, 2010 at 12:09 PM, Trevor Benson tben...@a-1networks.comwrote: 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.
Re: [pfSense Support] Routing issue between LAN and OPT1 when IPSEC enabled
On Wed, Jan 20, 2010 at 2:56 PM, Yehuda Katz yeh...@ymkatz.net wrote: Sounds to me like a NAT Reflection issue On Wed, Jan 20, 2010 at 5:51 PM, Oliver Hansen oliver.han...@gmail.comwrote: On Wed, Jan 20, 2010 at 2:18 PM, Chris Buechler cbuech...@gmail.comwrote: On Wed, Jan 20, 2010 at 2:55 PM, Oliver Hansen oliver.han...@gmail.com wrote: --snip-- Just last week, I set up a second VPN tunnel between the two routers. This one has the destination subnet of 192.168.50.0/24 and now from the hub router we can reach that subnet but from the 192.168.2.0/24 still cannot reach it. My thinking was that the router with LAN and OPT1 would either route between the two subnets and if not, it would send data up one VPN connection because it was interesting traffic and then it would get sent back down the 2nd tunnel to the other subnet. Neither of these things is happening. That traffic is going out IPsec because IPsec always wins over anything in the system routing table including other directly attached networks (just how it works in the FreeBSD kernel). You either have to not include that other local subnet within your remote IPsec definition, or use OpenVPN which will work properly in that scenario. Thanks for the reply. I can understand that IPsec always wins but why if it is getting sent up the VPN tunnel does it not get sent back down the second VPN tunnel to the 192.168.50.0/24 subnet? Any of my other networks such as 192.168.3.0/24 can send traffic to the .50 network and receive replies. Is there something about having two IPsec VPNs between the same two boxes that causes this not to work? Example A: 192.168.3.0/24 - 192.168.1.0/24 - 192.168.50.0/24 = successful Example B: 192.168.2.0/24 - 192.168.1.0/24 ---X 192.168.50.0/24 = no success I'm not sure how NAT reflection would be involved. My understanding of NAT reflection is that is enables users to access resources on the WAN IP that they are NATted through. This is not the case. It sounds like OpenVPN would be an easier fit here and had I known that before setting up all the connections I would have started with that. I am still trying to learn what is causing the one subnet not be able to reach the other through the VPN though when all other subnets can do this through IPsec.
Re: [pfSense Support] Routing issue between LAN and OPT1 when IPSEC enabled
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/24 cannot 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 On Jan 21, 2010, at 9:31 AM, Oliver Hansen wrote: On Wed, Jan 20, 2010 at 2:56 PM, Yehuda Katz yeh...@ymkatz.net wrote: Sounds to me like a NAT Reflection issue On Wed, Jan 20, 2010 at 5:51 PM, Oliver Hansen oliver.han...@gmail.com wrote: On Wed, Jan 20, 2010 at 2:18 PM, Chris Buechler cbuech...@gmail.com wrote: On Wed, Jan 20, 2010 at 2:55 PM, Oliver Hansen oliver.han...@gmail.com wrote: --snip-- Just last week, I set up a second VPN tunnel between the two routers. This one has the destination subnet of 192.168.50.0/24 and now from the hub router we can reach that subnet but from the 192.168.2.0/24 still cannot reach it. My thinking was that the router with LAN and OPT1 would either route between the two subnets and if not, it would send data up one VPN connection because it was interesting traffic and then it would get sent back down the 2nd tunnel to the other subnet. Neither of these things is happening. That traffic is going out IPsec because IPsec always wins over anything in the system routing table including other directly attached networks (just how it works in the FreeBSD kernel). You either have to not include that other local subnet within your remote IPsec definition, or use OpenVPN which will work properly in that scenario. Thanks for the reply. I can understand that IPsec always wins but why if it is getting sent up the VPN tunnel does it not get sent back down the second VPN tunnel to the 192.168.50.0/24 subnet? Any of my other networks such as 192.168.3.0/24 can send traffic to the .50 network and receive replies. Is there something about having two IPsec VPNs between the same two boxes that causes this not to work? Example A: 192.168.3.0/24 - 192.168.1.0/24 - 192.168.50.0/24 = successful Example B: 192.168.2.0/24 - 192.168.1.0/24 ---X 192.168.50.0/24 = no
Re: [pfSense Support] Routing issue between LAN and OPT1 when IPSEC enabled
On Wed, Jan 20, 2010 at 2:55 PM, Oliver Hansen oliver.han...@gmail.com wrote: I have hub and spoke VPN network setup. 192.168.1.0/24 is the hub (central office) and 192.168.x.0/24 are all the spokes (remote offices). These are all connected with IPSEC VPN connections running a mix of linksys vpn routers and pfSense 1.2.3-RC3. The problem I am having is related to two pfSense boxes running 1.2.3-RC3 (I'll update to RELEASE if that's really the problem but I'd rather wait a while). In most locations there is a single subnet at the remote offices and that works fine. The remote offices are all able to communicate to each other through the central office because on their routers the IPSEC remote subnet is 192.168.0.0/16. Here is the problem: at one location we have both 192.168.2.0/24 on LAN and 192.168.50.0/24 on OPT1. We have a VPN connection from the LAN to the hub office and that worked fine but neither computers on the 192.168.2.0/24 or the 192.168.1.0/24 could reach the 192.168.50.0/24 subnet. I determined that the reason must be that any packets from the LAN must be getting sent over the VPN tunnel before the router would check to see that it held that subnet on one of it's own interfaces. Just last week, I set up a second VPN tunnel between the two routers. This one has the destination subnet of 192.168.50.0/24 and now from the hub router we can reach that subnet but from the 192.168.2.0/24 still cannot reach it. My thinking was that the router with LAN and OPT1 would either route between the two subnets and if not, it would send data up one VPN connection because it was interesting traffic and then it would get sent back down the 2nd tunnel to the other subnet. Neither of these things is happening. That traffic is going out IPsec because IPsec always wins over anything in the system routing table including other directly attached networks (just how it works in the FreeBSD kernel). You either have to not include that other local subnet within your remote IPsec definition, or use OpenVPN which will work properly in that scenario. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Routing issue between LAN and OPT1 when IPSEC enabled
On Wed, Jan 20, 2010 at 2:18 PM, Chris Buechler cbuech...@gmail.com wrote: On Wed, Jan 20, 2010 at 2:55 PM, Oliver Hansen oliver.han...@gmail.com wrote: --snip-- Just last week, I set up a second VPN tunnel between the two routers. This one has the destination subnet of 192.168.50.0/24 and now from the hub router we can reach that subnet but from the 192.168.2.0/24 still cannot reach it. My thinking was that the router with LAN and OPT1 would either route between the two subnets and if not, it would send data up one VPN connection because it was interesting traffic and then it would get sent back down the 2nd tunnel to the other subnet. Neither of these things is happening. That traffic is going out IPsec because IPsec always wins over anything in the system routing table including other directly attached networks (just how it works in the FreeBSD kernel). You either have to not include that other local subnet within your remote IPsec definition, or use OpenVPN which will work properly in that scenario. Thanks for the reply. I can understand that IPsec always wins but why if it is getting sent up the VPN tunnel does it not get sent back down the second VPN tunnel to the 192.168.50.0/24 subnet? Any of my other networks such as 192.168.3.0/24 can send traffic to the .50 network and receive replies. Is there something about having two IPsec VPNs between the same two boxes that causes this not to work? Example A: 192.168.3.0/24 - 192.168.1.0/24 - 192.168.50.0/24 = successful Example B: 192.168.2.0/24 - 192.168.1.0/24 ---X 192.168.50.0/24 = no success
Re: [pfSense Support] Routing issue between LAN and OPT1 when IPSEC enabled
Sounds to me like a NAT Reflection issue On Wed, Jan 20, 2010 at 5:51 PM, Oliver Hansen oliver.han...@gmail.comwrote: On Wed, Jan 20, 2010 at 2:18 PM, Chris Buechler cbuech...@gmail.comwrote: On Wed, Jan 20, 2010 at 2:55 PM, Oliver Hansen oliver.han...@gmail.com wrote: --snip-- Just last week, I set up a second VPN tunnel between the two routers. This one has the destination subnet of 192.168.50.0/24 and now from the hub router we can reach that subnet but from the 192.168.2.0/24 still cannot reach it. My thinking was that the router with LAN and OPT1 would either route between the two subnets and if not, it would send data up one VPN connection because it was interesting traffic and then it would get sent back down the 2nd tunnel to the other subnet. Neither of these things is happening. That traffic is going out IPsec because IPsec always wins over anything in the system routing table including other directly attached networks (just how it works in the FreeBSD kernel). You either have to not include that other local subnet within your remote IPsec definition, or use OpenVPN which will work properly in that scenario. Thanks for the reply. I can understand that IPsec always wins but why if it is getting sent up the VPN tunnel does it not get sent back down the second VPN tunnel to the 192.168.50.0/24 subnet? Any of my other networks such as 192.168.3.0/24 can send traffic to the .50 network and receive replies. Is there something about having two IPsec VPNs between the same two boxes that causes this not to work? Example A: 192.168.3.0/24 - 192.168.1.0/24 - 192.168.50.0/24 = successful Example B: 192.168.2.0/24 - 192.168.1.0/24 ---X 192.168.50.0/24 = no success
Re: [pfSense Support] Routing issue with 2 pfS w/bridging setup (bridge works mostly)
On Mon, Aug 31, 2009 at 12:27 PM, Richard Amermanfi...@7technw.com wrote: I'm having a routing issue with a new double pfSense setup I have configured. Here is a diagram of the setup: http://tinyurl.com/mqko87 Both of the firewalls are pfSense 1.2.3-RC1 from the live-CD They each have 4 interfaces. Everything is working fine except for the following. I have two related issues at this time: 1. I can not ping from IP Phone Vancouver (192.168.20.0/24) to Skyport (172.16.48.0/24). I have a test PC (172.16.48.10) located at a switch connected to the LAN interface of the Skyport pfSense box. When I do a traceroute it just times out. IP Phone Vancouver can talk just fine to the local bridged segment of 172.16.48.1.0/24 just not the remote one (Vancouver). I know, the bridged part is silly but I have not choice, it is already here and can not be changed, at lest not now. 2. I can not ping from Skyport (172.16.48.1.0/24) to IP Phone (192.168.20.0/24). When I do a traceroute it heads out the wan interface and eventually times out. I have a static route setup on the pfsfwsky firewall for 192.168.20.0/24 with gateway of 192.168.20.1 There is no route listed for 192.168.20.0/24 in the 'Routing tables' in the gui Diagnostics Routes page. So it appears that the traffic is ignoring the static route, or the static route is not taking. The route is wrong, you have to use an IP the firewall has on a directly attached interface. You can't tell it to go to 192.168.20.x to reach 192.168.20.x. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Routing Issue
Ah, excellent... So i could have 85.116.xxx.1/29 on pfsense.left 85.116.xxx.2/29 on pfsense.right then 85.116.xxx.3/29 as virtual Great guns Lee alan walters wrote: Use vlans and then allocate each vlan to an interface. We use this a lot. Create the vlans Ie vlan 100 192.168.1.0/28 Vlan 200 192.168.1.16/28 Etc Assign vlan 100 to lan Assign vlan200 to opt1 And so on and so forth -Original Message- From: Lee Hetherington [mailto:[EMAIL PROTECTED] Sent: 22 February 2006 09:21 To: support@pfsense.com Subject: Re: [pfSense Support] Routing Issue Yea thats what im thinking. Shame really. Ill have to static nat it :( Also another thing I have 2 pfsense boxes on my live network with a /24 behind it. I want to chop up the /24 into multiple segments, each in its own vlan (Per customer) with its own gateway carp address and address per pfsense... I cant see a way of adding multiple networks to a interface, just virtual ip's. Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]