[pfSense Support] IPSEC changes without throwing off existing connections
Hi All: I was wondering if it's possible in a future release to add an IPSEC tunnel without bouncing all the existing tunnels off and having them re-negotiate. We use pfsense in a corporate environment with about 50 stores so I have to do any additions late at night after our call center closes. A colleague at another company reports their Linux Astaro thing doesn't do that - I don't use Linux at all in my enterprise and am certainly not about to pay a few grand for an underpowered Linux-based firewall. This feature would be greatly appreciated if it's possible. Thanks- Gabe
Re: [pfSense Support] tuning incoming load balancer
Bill Marquette wrote: > Yep, again, the load balance itself is performed in kernel. pf itself > doesn't really care about icmp unreachables (and that only addresses > the issue of Apache going down, not of the whole box crashing). OK, thanks for that clarification. BTW, we've been testing with and without the "stickiness" set and as far as we can tell 1.2RC2 doesn't actually do the round-robin load balancing, or just does the failover. I'd raise a bug but thought I'd check first. >>> I suppose the main questions here are how important it is that you ... > We could probably do to the nearest second (I'd suggest that the .. >> I am happy to have a hack at the code and/or be a beta tester for this. > I'll likely hit on this during the hackathon, I'll shoot you an email > in mid October. great! thanks again Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] Re: jabber and NAT woes
I have same issue with port forwarding. thought it was a config problem for me. I have SSH on a non-standard port on the WAN side and it is supposed to be forwarding to standard port 22 on the LAN side server. I get a connection established, but no data (not even a logon prompt) and then about 15 seconds later it will finally drop the connection. -Sean > Date: Wed, 26 Sep 2007 12:50:50 +1000> From: [EMAIL PROTECTED]> CC: > support@pfsense.com> Subject: [pfSense Support] Re: jabber and NAT woes> > > I've done a further test. I also get my connection dropped if I use ssh> and > ssh to a public IP address that is port forwarded to a server in the> LAN.> > > So I'm guessing this issue is something to do with NAT on pfSense,> rather > than ejabberd.> > Any help will be very appreciated.> > Geoff Crompton > wrote:> > We've just transition from using IPCop 1.4.13 to using pfSense > 1.2-RC2.> > The transition wasn't so bad. However we are having problems with > jabber> > connections now.> > > > Our ejabberd (version 1.1.2-6, from the > Etch Debian package) runs inside> > a vserver in our dmz zone. Our domain > name jabber.strategicdata.com.au> > resolves to the IP address on the WAN > interface (not an Virtual IP). We> > have configured NAT rules to port > forward the connections to the> > ejabberd vserver.> > > -- > Geoff Crompton> > Debian System Administrator> http://www.strategicdata.com.au> Phone: +61 3 > 9340 9000> Fax: +61 3 9348 2015> > > -> To > unsubscribe, e-mail: [EMAIL PROTECTED]> For additional commands, e-mail: > [EMAIL PROTECTED]> _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
Re: [pfSense Support] Re: jabber and NAT woes
Sean Cavanaugh wrote: > > I have same issue with port forwarding. thought it was a config problem > for me. I have SSH on a non-standard port on the WAN side and it is > supposed to be forwarding to standard port 22 on the LAN side server. I > get a connection established, but no data (not even a logon prompt) and > then about 15 seconds later it will finally drop the connection. what does "ssh -v" report? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Issue with stalling on static route
Hello all! I am having a major issue that I'm hoping you can shed light on. We recently added an MPLS link from our location to our other company offices (replacing a pfsense VPN tunnel that was working great) and am now having issues across it. The MPLS is hooked to a cisco router sitting behind our pfsense firewall, and I setup a static route on pfsense over to it for the appropriate subnet. This seemed to work fine, but after using it a bit it seems that traffic is getting stalled somewhere. If I setup a static route on my desktop machine (client machine on network) to the cisco (for the appropriate subnet) everything works perfectly. So it seems something is happening on the pfsense machine. Shorter transactions seem to be fine, pinging always works. Outlook however is very unhappy (consequently so are the users...). In general it seems that TCP services being effected most. I did a packet capture with and without the static route on my client machine. With all the traffic going through the pfsense there were a lot of TCP retransmissions happening. Could this be an issue with pfsense's packet scrubbing? There is nothing in the firewall logs to indicate that anything is being blocked. I am using 1.2RC2. If anyone has any ideas I would be very appreciative. I think the users are starting to gather torches and pitchforks... James- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Issue with stalling on static route
jamespev wrote: > works perfectly. So it seems something is happening on the pfsense > machine. Shorter transactions seem to be fine, pinging always works. try ping with a large payload > If anyone has any ideas I would be very appreciative. I think the > users are starting to gather torches and pitchforks... try reducing the MTU at both ends of the link down to say 1300. is icmp being blocked - might be breaking MTU path discovery, when that happens you get all sorts of odd effects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Re: jabber and NAT woes
Paul M wrote: > Sean Cavanaugh wrote: >> I have same issue with port forwarding. thought it was a config problem >> for me. I have SSH on a non-standard port on the WAN side and it is >> supposed to be forwarding to standard port 22 on the LAN side server. I >> get a connection established, but no data (not even a logon prompt) and >> then about 15 seconds later it will finally drop the connection. > > what does "ssh -v" report? > p.s. check MTU (reduce to 1300 to test) and blocking of ICMP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC changes without throwing off existing connections
Try a recent snapshot. Seth modified it to not bounce all connections on save. On 9/26/07, Gabriel Green <[EMAIL PROTECTED]> wrote: > Hi All: > > I was wondering if it's possible in a future release to add an IPSEC tunnel > without bouncing all the existing tunnels off and having them re-negotiate. > We use pfsense in a corporate environment with about 50 stores so I have to > do any additions late at night after our call center closes. > > A colleague at another company reports their Linux Astaro thing doesn't do > that - I don't use Linux at all in my enterprise and am certainly not about > to pay a few grand for an underpowered Linux-based firewall. > > This feature would be greatly appreciated if it's possible. > > Thanks- > Gabe > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Issue with stalling on static route
jamespev wrote: Hello all! I am having a major issue that I'm hoping you can shed light on. We recently added an MPLS link from our location to our other company offices (replacing a pfsense VPN tunnel that was working great) and am now having issues across it. The MPLS is hooked to a cisco router sitting behind our pfsense firewall, and I setup a static route on pfsense over to it for the appropriate subnet. This seemed to work fine, but after using it a bit it seems that traffic is getting stalled somewhere. If I setup a static route on my desktop machine (client machine on network) to the cisco (for the appropriate subnet) everything works perfectly. So it seems something is happening on the pfsense machine. Shorter transactions seem to be fine, pinging always works. Outlook however is very unhappy (consequently so are the users...). In general it seems that TCP services being effected most. I did a packet capture with and without the static route on my client machine. With all the traffic going through the pfsense there were a lot of TCP retransmissions happening. Could this be an issue with pfsense's packet scrubbing? There is nothing in the firewall logs to indicate that anything is being blocked. I am using 1.2RC2. If anyone has any ideas I would be very appreciative. I think the users are starting to gather torches and pitchforks... James You haven't specified what MPLS-based service(s) you're taking! First point of call for all MPLS-related issues : have you made sure you can pass full 1500-byte frames across the circuit? adam. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] Adding new NIC drivers
OK, after many problems, like couldn't install because of no known NICs, installing NICs in a 1U case with no riser, figuring out how to mount, if_myk.ko requiring libmbpool.ko, etc., I finally got the drivers installed with kldload and they appear to work. Until I rebooted. The drivers don't reload. What to do I need to change in order to get them to install permanently? --Bennett Bill Marquette wrote: > >Probably easiest to load them onto a USB keyfob and mount it after boot. Then kldload the if_myk.ko module. > >--Bill > >On 9/25/07, Bennett Lee <[EMAIL PROTECTED]> wrote: >> I've got a new motherboard with quad-GB LANs that all use Marvell >> 8056, which isn't supported by pfSense/FreeBSD. I d/l Marvell's "Yukon" >> FreeBSD drivers, which supposedly support this board. Their .tgz >> contains if_myk.ko, +CONTENTS, and myk.4.gz. Inside myk.4.gz is myk.4. >> >> How do I add these drivers to the LiveCD so I can try them out? Is it >> as easy as injecting the files into the CD into some particular folder >> and maybe adding them to a boot config file? (I hope so--haven't done >> anything in *nix since I wrote a crappy little client/server app back >> in college [many, many, many] years ago.) >> >> --Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Auto Refresh of Screens are a problem at times
I would like to know if there is a way to disable the auto refresh of PfSense screens, especially in the potentially long page displays (DHCP, Captive Portal Users, etc.). There have been several times when I finally locate an item of information on the page and the refresh occurs, which puts the display back to the TOP. I would like a PAUSE button or manual REFRESH. Thanks. Fred Dziuk The University of Texas Health Science Center at San Antonio Systems and Network Operations
Re: [pfSense Support] No carrier on SYNC interface
"went through fine both times. Just probably that I and others have never heard of or seen a pfsync change cause a loss of link." Ahh, I sense some tough love here. I had assumed that my post would be echoed back out to me, but either the mailing list server or gmail didn't do this. "It's your switch's spanning tree protocol that's doing this, not pfSense. Unfortunately right now pfS has no concept of STP and will happily create a L2 loop if that's what you tell it to do. It's not "annoying" that this happens, it's required for your network to function." I'm no firewall programming network guru, if I was i'd be working with you already on the project, so please forgive some lack of detailed knowledge of the system. But since I was using inexpensive switches I had assumed pfSense had initiated the blocking, mostly because when you check ifconfig it shows one side of the bridge in blocking mode, as opposed to the whole interface. Therefore given that it seemed as though pfSense initiated the blocking, I was referring to the fact that it was "annoying" that the LAN was being blocked, as opposed to the WAN. Because that instantly makes it that much harder to configure the thing if no WAN access rule had been created yet. Not that the idea of blocking was "annoying" because I full understand the importance of blocking the loop. It should be noted I suppose that using the same hardware I did have a transparent bridge + CARP setup up and working. I tested connecting into a block behind the transparent bridge, and pulled the power on the non blocking firewall, and after about 45 seconds (give or take) I was able to continue working as normal, as the other firewall unblocked itself and allowed traffic. But you're saying this wasn't due to pfSense's abilities? But rather the switches unblocked the ports? That's unfortunate. Are there any plans in the future to implement this into pfSense? It would open up the enterprise market like crazy, being able to inexpensively implement a redundant transparent firewall/bridge. On 9/25/07, Chris Buechler <[EMAIL PROTECTED]> wrote: > > Shane B wrote: > > -- > > posted this this morning, but did not seem to have gone through > > went through fine both times. Just probably that I and others have never > heard of or seen a pfsync change cause a loss of link. > > > Note: One small problem I run into is that it seems that pfSense > > indiscriminately blocks one of the interfaces to keep from creating an > > ethernet loop, which is annoying during initial setup. My fix is just > > unplugging one of the WAN interfaces til i've completed setup. > > It's your switch's spanning tree protocol that's doing this, not > pfSense. Unfortunately right now pfS has no concept of STP and will > happily create a L2 loop if that's what you tell it to do. It's not > "annoying" that this happens, it's required for your network to > function. If your switch didn't shut down one of the ports, your whole > network would be completely dead in about 5 seconds from the loop. > Actually one of the boxes' WAN ports should never come up unless the > other's port goes down. > > Bridging + CARP isn't a recommended configuration and I don't believe it > works properly at all (possibly depending on switch configuration) > without a hack shell script I recall seeing either on this list or the > forum. Maybe somebody remembers where it was posted and has a link. It > checks to see if the box is currently the master, and if so, it brings > up the bridge interface if it isn't already. So the bridge stays down > until the box becomes master, and then brings up the bridge. It's a > hack, but the person who wrote it has it working. > > No clue what the no carrier on the pfsync interface might be, maybe > somebody else will chime in. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [pfSense Support] jabber and NAT woes
Hi, I ran in to this one too. The basic issue is that jabber leaves its TCP connection open but idle when there's no actual messaging traffic going on, and pfSense's scheme to implement NAT reflection (ie. accessing the "public" IP address from the LAN) depends on the use of a TCP proxy that has a fixed timeout (although IIRC there's currently a hidden option that allows adjusting the specific timeout). In this case adjusting the state timeout won't help because it's not the state table that's timing out - it's the TCP proxy. The quickest "fix" is to use the DNS proxy on your pfSense box and set a fixed mapping of the external name to the internal IP of the server. This forces the internal client boxes to connect directly, and still allows external clients to operate normally through the firewall (since they resolve DNS against the public DNS servers that carry the correct external IP). Another "fix" is to adjust the TCP proxy timeout - I'm not sure where that lives currently, although IIRC it's not accessible from the GUI; the details are in the forums somewhere. Unfortunately, this can lead to dead proxy processes kicking around on your pfSense box for long periods of time before they time out, but at least the live connections don't go with them. The Linux kernel supports doing NAT reflection directly in the kernel, which is why it 'just works' with IPCop. Unfortunately, the FreeBSD gurus claim that their NAT system is not capable of doing this within the packet filtering framework. That said, it /is/ possible to trick it into behaving this way, and I assembled a patch for my own usage to solve this specific problem, but since the experts claim it's not possible there's no guarantee it will behave correctly in all circumstances. I'll see if I can get it together over the weekend - I'm still using one of the 1.2 betas, though, so it'd take me a bit to update it for the RC build. That said, it doesn't remove the proxy-based reflection scheme, so if you're interested in the patch you can always go back to whichever model you find works best for you. -Will Miles On Wed, 26 Sep 2007 12:39:34 +1000 Geoff Crompton <[EMAIL PROTECTED]> wrote: > We've just transition from using IPCop 1.4.13 to using pfSense 1.2-RC2. > The transition wasn't so bad. However we are having problems with jabber > connections now. > > Our ejabberd (version 1.1.2-6, from the Etch Debian package) runs inside > a vserver in our dmz zone. Our domain name jabber.strategicdata.com.au > resolves to the IP address on the WAN interface (not an Virtual IP). We > have configured NAT rules to port forward the connections to the > ejabberd vserver. > > This works for clients connecting from the Internet. It also works for > clients connecting from the LAN that connect directly to the vserver > address. > > However if a LAN client connects to jabber.strategicdata.com.au, and > hence to the public IP address, they can connect, and they get > disconnected a few minutes later. > > Does anyone know how I can debug this further? > > The ejabberd logs currently show that the dropping clients have a source > IP address that corresponds to the dmz interface IP address on the > pfSense router. The logs from when we were running IPCop 1.4.13 showed > that ejabberd saw the connections coming from the LAN interface IP > address. I'm not sure if this is significant, because in both cases the > IP address doesn't correspond to where the client really is coming from. > > -- > Geoff Crompton > Debian System Administrator > http://www.strategicdata.com.au > Phone: +61 3 9340 9000 > Fax: +61 3 9348 2015 > > - > 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]
Re: [pfSense Support] Issue with stalling on static route
>> You haven't specified what MPLS-based service(s) you're taking! >> First point of call for all MPLS-related issues : have you made sure you >> can pass full 1500-byte frames across the circuit? This is IP over MPLS (I think that is what it would be called). I did use iperf to run traffic over the link, and I sent 1500 byte frames with success. I also saw good bandwidth and low packet loss. Again, it only has issues when the traffic is routed through pfsense... if I set a static route from my desktop to the cisco MPLS router it works just fine. As you might expect, only outgoing traffic is effected as incoming should be bypassing pfsense either way. It seems that the outgoing traffic just stops flowing through pfsense. When I wireshark an rdesktop session it freezes and looking at the packet capture my machine was sending TCP retransmissions for a few minutes which did not appear to be getting through. Could this be a states issue? Are states created for routed traffic? Thanks for the ideas guys, I'm pretty stumped as to whats going on here. Seems like a pretty straightforward setup. James - 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]
Re: [pfSense Support] hotplug event on LAN triggers problem on PPTP WAN
Chris Buechler wrote on 26-9-2007 2:02: Jan Hoevers wrote: It seems as if the system interprets a hotplug event on any ethernet port as if it were on the WAN port. What's going on? I'm running a server, so it's quite inconvenient. There was no problem on 1.0.1, so downgrading is an option, but maybe something better is at hand. Definitely sounds like a bug. I opened a ticket. If you can, please hang on with 1.2rc2 for the time being. None of the developers have a PPTP WAN, so we'll need somebody to test the change with that specific setup. Ok, fine. For now, I remain with 1.2RC2, leaving all equipment on as a workaround. I may downgrade, but I have a spare soekris and would be pleased to do any testing if you want me to. thanks, Jan Hoevers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Issue with stalling on static route
check the box to bypass firewall rules for traffic leaving the same interface it enters on the Advanced page. jamespev wrote: Hello all! I am having a major issue that I'm hoping you can shed light on. We recently added an MPLS link from our location to our other company offices (replacing a pfsense VPN tunnel that was working great) and am now having issues across it. The MPLS is hooked to a cisco router sitting behind our pfsense firewall, and I setup a static route on pfsense over to it for the appropriate subnet. This seemed to work fine, but after using it a bit it seems that traffic is getting stalled somewhere. If I setup a static route on my desktop machine (client machine on network) to the cisco (for the appropriate subnet) everything works perfectly. So it seems something is happening on the pfsense machine. Shorter transactions seem to be fine, pinging always works. Outlook however is very unhappy (consequently so are the users...). In general it seems that TCP services being effected most. I did a packet capture with and without the static route on my client machine. With all the traffic going through the pfsense there were a lot of TCP retransmissions happening. Could this be an issue with pfsense's packet scrubbing? There is nothing in the firewall logs to indicate that anything is being blocked. I am using 1.2RC2. If anyone has any ideas I would be very appreciative. I think the users are starting to gather torches and pitchforks... James - 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]
Re: [pfSense Support] hotplug event on LAN triggers problem on PPTP WAN
Chris Buechler wrote on 26-9-2007 2:02: Definitely sounds like a bug. I opened a ticket. If you can, please hang on with 1.2rc2 for the time being. None of the developers have a PPTP WAN, so we'll need somebody to test the change with that specific setup. Maybe the following additional information is helpful: I've now put an ethernet switch between the LAN interface of the pfSense box and my desktop computer. Power cycling the desktop computer now doesn't trigger the reported problem (as it did when connected directly). Power cycling the switch however does. I believe this confirms the problem comes from the ethernet hotplugging (and not from dhcp or whatever else). Please let me know if you need more information. regards, Jan Hoevers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] hotplug event on LAN triggers problem on PPTP WAN
Jan Hoevers wrote: Chris Buechler wrote on 26-9-2007 2:02: Definitely sounds like a bug. I opened a ticket. If you can, please hang on with 1.2rc2 for the time being. None of the developers have a PPTP WAN, so we'll need somebody to test the change with that specific setup. Maybe the following additional information is helpful: I've now put an ethernet switch between the LAN interface of the pfSense box and my desktop computer. Power cycling the desktop computer now doesn't trigger the reported problem (as it did when connected directly). Power cycling the switch however does. I believe this confirms the problem comes from the ethernet hotplugging (and not from dhcp or whatever else). Sure does, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] jabber and NAT woes
Will Miles wrote: The Linux kernel supports doing NAT reflection directly in the kernel, which is why it 'just works' with IPCop. Unfortunately, the FreeBSD gurus claim that their NAT system is not capable of doing this within the packet filtering framework. That said, it /is/ possible to trick it into behaving this way, and I assembled a patch for my own usage to solve this specific problem, but since the experts claim it's not possible there's no guarantee it will behave correctly in all circumstances. I'll see if I can get it together over the weekend - I'm still using one of the 1.2 betas, though, so it'd take me a bit to update it for the RC build. That said, it doesn't remove the proxy-based reflection scheme, so if you're interested in the patch you can always go back to whichever model you find works best for you. I don't think anyone's ever said it isn't possible, the things I recall reading were more along the lines of not wanting to do it. I don't recall the reasoning offhand. If you have some change that makes it work, it would be interesting to see. Please post it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] No carrier on SYNC interface
Shane B wrote: "went through fine both times. Just probably that I and others have never heard of or seen a pfsync change cause a loss of link." Ahh, I sense some tough love here. I had assumed that my post would be echoed back out to me, but either the mailing list server or gmail didn't do this. Nah, just confirming that it did go through, and a lot of times when people put that they're insinuating "why didn't anybody reply", and I was just explaining. With a normal mail client, you will get the message from the list, but gmail never shows you your own posts from the list. Even when it comes back to you with a modified subject line, which annoys me for the lists I use in gmail. Even the replies come back without the modified subject. Then some of your archived posts from the list have modified subjects throughout the thread, and some don't. You can check the archive at gmane.org to verify it went out to the list. I'm no firewall programming network guru, if I was i'd be working with you already on the project, so please forgive some lack of detailed knowledge of the system. But since I was using inexpensive switches I had assumed pfSense had initiated the blocking, mostly because when you check ifconfig it shows one side of the bridge in blocking mode, as opposed to the whole interface. Interesting... did somebody add STP and I missed it? :) Are these unmanaged switches? If so, they won't do STP, or at least I've never seen or heard of an unmanaged switch with STP, and have dealt with idiots doing things like plugging both ends of a patch cable into an unmanaged switch, which has the result you'd expect. Now it sounds to me like there is STP functionality in pfS, though it's the first I've heard of it. Having never setup anything like this, I'm going to refrain from commenting further. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] jabber and NAT woes
realistically you don't want to do anything not directly kernel related in kernel space. that's the reason old windows would Blue Screen when a word document loaded incorrectly. kernel should be untouched and as such will make for a much more reliable OS, hence why FreeBSD is way more stable than linux. just because you can, doesn't mean you should. -Sean - Original Message - From: "Chris Buechler" <[EMAIL PROTECTED]> To: Sent: Wednesday, September 26, 2007 9:03 PM Subject: Re: [pfSense Support] jabber and NAT woes Will Miles wrote: The Linux kernel supports doing NAT reflection directly in the kernel, which is why it 'just works' with IPCop. Unfortunately, the FreeBSD gurus claim that their NAT system is not capable of doing this within the packet filtering framework. That said, it /is/ possible to trick it into behaving this way, and I assembled a patch for my own usage to solve this specific problem, but since the experts claim it's not possible there's no guarantee it will behave correctly in all circumstances. I'll see if I can get it together over the weekend - I'm still using one of the 1.2 betas, though, so it'd take me a bit to update it for the RC build. That said, it doesn't remove the proxy-based reflection scheme, so if you're interested in the patch you can always go back to whichever model you find works best for you. I don't think anyone's ever said it isn't possible, the things I recall reading were more along the lines of not wanting to do it. I don't recall the reasoning offhand. If you have some change that makes it work, it would be interesting to see. Please post it. - 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]
[pfSense Support] Re: 2 networks on the LAN interface, vlan, trunk?
Could someone at least tell me if this is feasible or not? Thanks Ugo (sorry for top-posting) Ugo Bellavance wrote: Hi, Here is my situation: I have a PfSense firewall and a switch that supports VLANs. I created 3 VLANS on this switch: VLAN 101 contains ports that are connected directly to the internet (PfSense WAN port, internet port (it is in colocation), other servers that would be connected directly to the internet (not behind PfSense). VLAN 102 contains ports that are connected to devices in the Subnet1, let's say 10.10.10.0/24. VLAN 103 contains ports that are connected to devices in the Subnet2, let's say 192.168.10.0/24. I left the default VLAN 1 that includes all ports. I've given 10.10.10.1 as IP address to the PfSense' LAN interface, and added a proxy arp virtual IP of 192.168.10.1. I configured the WAN interface of the PfSense to be part of VLAN 101. I configured the LAN interface of the PfSense to be part of VLAN 102 and 103. My goal is that even if I have only 2 interfaces on the PfSense system, I'd like to have 2 separate subnets on the LAN interface. This way, servers in the Subnet1 cannot talk directly to the servers in Subnet2, without going through firewall rules. Right now, everything is fine for subnet1. It can connect to the internet, to the firewall. I configured 1-to-1 NAT and allowed SSH in for some hosts and it can connect. However, subnet2 is completely isolated. It cannot talk to anyone, nor to the fw, nor the subnet1, nor the internet. I know I should have used another firewall or a firewall with 3 interfaces, but I thought what I'm trying to do is possible. Is it? If it is, where is my mistake(s)? Please let me know if you need more information. Regards, Ugo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] No carrier on SYNC interface
"Are these unmanaged switches?" Yeap, little 5 port workgroup switches (Linksys EZXS55W http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=US%2FLayout&cid=1115416836711&pagename=Linksys%2FCommon%2FVisitorWrapper ) I'll look into pfSense and STP a bit further. Thanks =) On 9/26/07, Chris Buechler <[EMAIL PROTECTED]> wrote: > > Shane B wrote: > > "went through fine both times. Just probably that I and others have > never > > heard of or seen a pfsync change cause a loss of link." > > > > Ahh, I sense some tough love here. I had assumed that my post would > > be echoed back out to me, but either the mailing list server or gmail > > didn't do this. > > Nah, just confirming that it did go through, and a lot of times when > people put that they're insinuating "why didn't anybody reply", and I > was just explaining. > > With a normal mail client, you will get the message from the list, but > gmail never shows you your own posts from the list. Even when it comes > back to you with a modified subject line, which annoys me for the lists > I use in gmail. Even the replies come back without the modified subject. > Then some of your archived posts from the list have modified subjects > throughout the thread, and some don't. You can check the archive at > gmane.org to verify it went out to the list. > > > > I'm no firewall programming network guru, if I was i'd be working with > > you already on the project, so please forgive some lack of detailed > > knowledge of the system. But since I was using inexpensive switches I > > had assumed pfSense had initiated the blocking, mostly because when > > you check ifconfig it shows one side of the bridge in blocking mode, > > as opposed to the whole interface. > > Interesting... did somebody add STP and I missed it? :) > > Are these unmanaged switches? If so, they won't do STP, or at least I've > never seen or heard of an unmanaged switch with STP, and have dealt with > idiots doing things like plugging both ends of a patch cable into an > unmanaged switch, which has the result you'd expect. > > Now it sounds to me like there is STP functionality in pfS, though it's > the first I've heard of it. > > Having never setup anything like this, I'm going to refrain from > commenting further. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
