Re: [pfSense Support] Routing Issue

2010-09-05 Thread Hans Maes

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

2010-09-05 Thread Ron Lemon
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

2010-09-05 Thread Ron Lemon
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

2010-01-25 Thread Oliver Hansen
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

2010-01-21 Thread Oliver Hansen
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

2010-01-21 Thread Trevor Benson
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

2010-01-20 Thread Chris Buechler
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

2010-01-20 Thread Oliver Hansen
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

2010-01-20 Thread Yehuda Katz
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)

2009-08-31 Thread Chris Buechler
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

2006-02-22 Thread Lee Hetherington

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]