Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-06 Thread Steve Yates
Chris L wrote on Fri, Feb 27 2015 at 12:10 pm: > Hopefully the provider can just route the additional subnet to your existing > WAN IP. Then you don’t need to do anything with CARP/HA except make sure > primary and secondary are both set up to deal with the routed traffic. I think sleep

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-02 Thread Adam Thompson
So if you don't wind up using them for CARP, use them for something else. Get a smaller subnet from your provider and give back the original subnet. If you have multiple subnets, the provider-facing one should not be used for published services; in fact those addresses don't even have to be publ

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-02 Thread Steve Yates
> Using CARP implies that you care about reliability during edge cases and > partial failures. If so, then you need to do it right and use 3 IPs where > you want 1 carp. I hear you. I guess part of me just dislikes the possibility of "wasting" 12 or 18 IPs (6 per subnet) a few years down the

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-02 Thread ED Fochler
Yes, get them now. If you don’t then they’ll go to someone else and you won’t be able to expand in a contiguous block. Using CARP implies that you care about reliability during edge cases and partial failures. If so, then you need to do it right and use 3 IPs where you want 1 carp. 3 on upli

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-02 Thread Steve Yates
Steve Yates wrote on Mon, Mar 2 2015 at 9:09 am: > I received an email directly...to perhaps shorten my example, if we > have two public subnets 1.1.1.0/28 and 2.2.2.0/28, I would like to use both of > those subnets on different servers, use pfSense as the firewall, and use CARP. > Is there

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-02 Thread Steve Yates
Steve Yates wrote on Mon, Mar 2 2015 at 1:05 am: > the scenario is: no NAT, multiple public IPs in use on the "LAN" side > from two different subnets, and pfSense acting as a firewall. I received an email directly...to perhaps shorten my example, if we have two public subnets 1.1.1.0/2

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-02 Thread Adam Thompson
Steve, Unless you want to impose significant limitations on yourself, you will need a total of 3 IPs for every CARP interface. I've run systems with single-IP CARP, and unless you have absolutely no choice, it's not worth the headache. The unanswered question is how your provider will do routing,

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-03-01 Thread Steve Yates
Chris L wrote on Fri, Feb 27 2015 at 3:34 pm: >> On Feb 27, 2015, at 12:37 PM, Steve Yates wrote: >> >> Chris L wrote on Fri, Feb 27 2015 at 12:10 pm: >> >>> Hopefully the provider can just route the additional subnet to your >>> existing WAN IP. Then you don’t need to do anything with CARP/HA

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Chris L
> On Feb 27, 2015, at 12:37 PM, Steve Yates wrote: > > Chris L wrote on Fri, Feb 27 2015 at 12:10 pm: > >> Hopefully the provider can just route the additional subnet to your existing >> WAN IP. Then you don’t need to do anything with CARP/HA except make sure >> primary and secondary are both

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Steve Yates
Chris L wrote on Fri, Feb 27 2015 at 12:10 pm: > Hopefully the provider can just route the additional subnet to your existing > WAN IP. Then you don’t need to do anything with CARP/HA except make sure > primary and secondary are both set up to deal with the routed traffic. Would that req

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Steve Yates
Steve Yates wrote on Fri, Feb 27 2015 at 12:29 pm: > Two WAN IP, two LAN IP, and two more for sync. And reading this, I didn't write what I meant, so to just correct it all, 3 WAN, 3 LAN, and 2 for sync. -- Steve Yates ITS, Inc. ___ pfSense

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Steve Yates
Chris L wrote on Fri, Feb 27 2015 at 12:32 pm: > Three, actually. One for each interface and one shared CARP address. I'm glad Chuck asked. I looked at that page several times and read right past the shared one on the WAN side. D'oh! Well never mind my other reply to you... -- S

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Chris L
> On Feb 27, 2015, at 10:21 AM, Chuck Mariotti wrote: > > I am starting this weekend to setup the same situation... So a simple > failover situation requires that we have TWO public IP addresses then? > I am starting to second guess if it's smart to use a VLAN on a shared switch. > If it fails

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Steve Yates
Chuck Mariotti wrote on Fri, Feb 27 2015 at 12:21 pm: > I am starting this weekend to setup the same situation... So a simple failover > situation requires that we have TWO public IP addresses then? That's what I took from https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Re

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Chuck Mariotti
I am starting this weekend to setup the same situation... So a simple failover situation requires that we have TWO public IP addresses then? I am starting to second guess if it's smart to use a VLAN on a shared switch. If it fails, then I have more problems at multiple levels vs. a simple dumb s

Re: [pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Chris L
Hopefully the provider can just route the additional subnet to your existing WAN IP. Then you don’t need to do anything with CARP/HA except make sure primary and secondary are both set up to deal with the routed traffic. > On Feb 27, 2015, at 9:59 AM, Steve Yates wrote: > > After learni

[pfSense] Running as a VM, multiple WAN subnets

2015-02-27 Thread Steve Yates
After learning of the CARP failover/sync features, we intend to use a VM based firewall for our new private cloud, and have it sync to a failover that would also be a VM. If it all works, we would be able to move the VMs around our cluster as necessary, while they are in use. We figure