Re: [pfSense Support] To integrate AD users to specific rule groups
On 7/30/2011 9:17 AM, Isamar Maia wrote: Ok. Great. Thanks for the tip, dude. Anyone knows an workaround for the item 2 ? Thanks, Isamar 2011年7月30日10:10 Chris Clark ch...@belthasar.com mailto:ch...@belthasar.com: Isamar, The captive portal in m0n0wall/pfSense isn’t capable of direct LDAP queries, unless something has changed recently. However, it is capable of RADIUS authentication. Since you have an Active Directory environment, it’s a trivial matter to setup IAS (2003) or NPS (2008) to handle RADIUS requests on one of your domain controllers. I’m not aware of a method to accomplish item two. Chris *From:*Isamar Maia [mailto:isa...@gmail.com mailto:isa...@gmail.com] *Sent:* Saturday, July 30, 2011 7:15 AM *To:* support@pfsense.com mailto:support@pfsense.com *Subject:* [pfSense Support] To integrate AD users to specific rule groups Hi Folks, Is there any way with PfSense to integrate AD authenticated users with rules groups. I mean, we wish to: 1) Integrate the Captive portal functionality to authenticate users to the Windows AD server 2) Attach specific users to specific firewall and squid filtering rules. Like: HR departament users can access only HR related sites,etc. Is that currently possible ? -- Isamar Maia Cel. VIVO SSA: (55) 71-9146-8575 Cel. TIM SSA: (55) 71-9185-5264 Fixo: (55) 71-4062-8688 日本: +81-(0)3-4550-1212 Skype ID: isamar.maia -- Isamar Maia Cel. VIVO SSA: (55) 71-9146-8575 Cel. TIM SSA: (55) 71-9185-5264 Fixo: (55) 71-4062-8688 日本: +81-(0)3-4550-1212 Skype ID: isamar.maia The Squid Package for PFSense looks like it will authenticate to a local database, Radius, LDAP, or NT Domain. There are also some ACL capabilities in the SquidGuard package. I'm not aware of any way to configure firewall rules on PFSense that communicate with an authentication back-end.
Re: [pfSense Support] L7 queue seems not to work
On 5/4/2011 11:37 AM, Vaughn L. Reid III wrote: On 5/4/2011 11:18 AM, Ermal Luçi wrote: On Wed, May 4, 2011 at 4:47 PM, Vaughn L. Reid III vaughn_reid_...@elitemail.org wrote: On 4/29/2011 4:49 PM, bsd wrote: Le 29 avr. 2011 à 19:08, bsd a écrit : Le 29 avr. 2011 à 09:37, bsd a écrit : Hi, I have created a simple L7 container where I have put SIP and SkypeOut traffic. Then created a Queue called VoIP where this traffic is supposed to end (HFSC with 10% reserved). Then two floating rule to put all traffic (TCP and UDP) in and selected the VoIP L7 container I have created. No traffic seems to go in that queue ?? Any hints ? Is L7 traffic shapping Out of order for the time beeing ? Thanks. May I had that my WLAN and LAN are bridged … If this has any impact on the L7 Queuing. … and that my other queue (non L7) are also working very correctly. Thx. And the system tunables have been set correctly… net.link.bridge.pfil_member Set to 0 to disable filtering on the incoming and outgoing member interfaces. 0 net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface1 No one has any feedback on L7 that and v.2.0.RC1 ? Here is some feedback on my experience with the L7 filter: With this morning's snapshot (05/04/2011 approximately 06:00 EST was the time I initiated a snapshot update), I have experienced the L7 filter significantly slowing web traffic on a system containing Squid and Squidguard once there were more than a couple of users sending traffic through the firewall. Disabling the firewall rule passing traffic to the L7 filter eliminated the bottleneck. Hardware is a a Core 2 Duo Processor, 4 Gigs memory, Supermicro Server Board, Intel Server NIC's. Also, no other traffic shaping other than a single L7 filter rule to block peer-to-peer traffic was enabled. I would recommend putting a firewall rule to send traffic to layer 7 on the outging side when squid is in place or either just filter the tcp 80/443 through squid and the other through layer7 with rules on the lan side. That's a good idea. Squid is running on the pfsense box, however, so I'm not sure I can create explicit rules for either option. Maybe send ports 80 and 443 to 127.0.0.1? On an alix system with a 2.0 RC1 update from last night (Wednesday 5/5/2011) and no squid or squidguard installed, the L7 filter set to block several peer-to-peer protocols completely bogged down Internet access, effectively disabling web, mail, and other traffic. Disabling the LAN rule that activated the L7 filter on that interface instantly re-enabled the normal passage of traffic. - 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] L7 queue seems not to work
On 4/29/2011 4:49 PM, bsd wrote: Le 29 avr. 2011 à 19:08, bsd a écrit : Le 29 avr. 2011 à 09:37, bsd a écrit : Hi, I have created a simple L7 container where I have put SIP and SkypeOut traffic. Then created a Queue called VoIP where this traffic is supposed to end (HFSC with 10% reserved). Then two floating rule to put all traffic (TCP and UDP) in and selected the VoIP L7 container I have created. No traffic seems to go in that queue ?? Any hints ? Is L7 traffic shapping Out of order for the time beeing ? Thanks. May I had that my WLAN and LAN are bridged … If this has any impact on the L7 Queuing. … and that my other queue (non L7) are also working very correctly. Thx. And the system tunables have been set correctly… net.link.bridge.pfil_member Set to 0 to disable filtering on the incoming and outgoing member interfaces. 0 net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface1 No one has any feedback on L7 that and v.2.0.RC1 ? Here is some feedback on my experience with the L7 filter: With this morning's snapshot (05/04/2011 approximately 06:00 EST was the time I initiated a snapshot update), I have experienced the L7 filter significantly slowing web traffic on a system containing Squid and Squidguard once there were more than a couple of users sending traffic through the firewall. Disabling the firewall rule passing traffic to the L7 filter eliminated the bottleneck. Hardware is a a Core 2 Duo Processor, 4 Gigs memory, Supermicro Server Board, Intel Server NIC's. Also, no other traffic shaping other than a single L7 filter rule to block peer-to-peer traffic was enabled. - 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] L7 queue seems not to work
On 5/4/2011 11:18 AM, Ermal Luçi wrote: On Wed, May 4, 2011 at 4:47 PM, Vaughn L. Reid III vaughn_reid_...@elitemail.org wrote: On 4/29/2011 4:49 PM, bsd wrote: Le 29 avr. 2011 à 19:08, bsd a écrit : Le 29 avr. 2011 à 09:37, bsd a écrit : Hi, I have created a simple L7 container where I have put SIP and SkypeOut traffic. Then created a Queue called VoIP where this traffic is supposed to end (HFSC with 10% reserved). Then two floating rule to put all traffic (TCP and UDP) in and selected the VoIP L7 container I have created. No traffic seems to go in that queue ?? Any hints ? Is L7 traffic shapping Out of order for the time beeing ? Thanks. May I had that my WLAN and LAN are bridged … If this has any impact on the L7 Queuing. … and that my other queue (non L7) are also working very correctly. Thx. And the system tunables have been set correctly… net.link.bridge.pfil_member Set to 0 to disable filtering on the incoming and outgoing member interfaces. 0 net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface1 No one has any feedback on L7 that and v.2.0.RC1 ? Here is some feedback on my experience with the L7 filter: With this morning's snapshot (05/04/2011 approximately 06:00 EST was the time I initiated a snapshot update), I have experienced the L7 filter significantly slowing web traffic on a system containing Squid and Squidguard once there were more than a couple of users sending traffic through the firewall. Disabling the firewall rule passing traffic to the L7 filter eliminated the bottleneck. Hardware is a a Core 2 Duo Processor, 4 Gigs memory, Supermicro Server Board, Intel Server NIC's. Also, no other traffic shaping other than a single L7 filter rule to block peer-to-peer traffic was enabled. I would recommend putting a firewall rule to send traffic to layer 7 on the outging side when squid is in place or either just filter the tcp 80/443 through squid and the other through layer7 with rules on the lan side. That's a good idea. Squid is running on the pfsense box, however, so I'm not sure I can create explicit rules for either option. Maybe send ports 80 and 443 to 127.0.0.1? - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/10/2011 7:58 PM, Vaughn L. Reid III wrote: On 2/10/2011 7:30 PM, Moshe Katz wrote: Is your ISP Verizon? We have had many ARP issues with Verizon FIOS. For our pfSense box to get all of our IPs, we have to manually set each of the IPs as the WAN IP (one by one), then set up the Virtual IP settings after we do that. Moshe -- Moshe Katz -- mo...@ymkatz.net mailto:mo...@ymkatz.net -- +1(301)867-3732 On Thu, Feb 10, 2011 at 7:19 PM, Vaughn L. Reid III vaughn_reid_...@elitemail.org mailto:vaughn_reid_...@elitemail.org wrote: On 2/10/2011 12:57 PM, Evgeny Yurchenko wrote: On 11-02-10 11:07 AM, Vaughn L. Reid III wrote: On 2/10/2011 10:42 AM, Vaughn L. Reid III wrote: On 2/10/2011 9:32 AM, Vaughn L. Reid III wrote: On 2/10/2011 2:43 AM, Seth Mos wrote: Op 10-2-2011 4:18, Vaughn L. Reid III schreef: 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). Yes, some switch support multicast filtering, I know from experience with HP switches that it works with the setting on. So I know they have it implemented correctly. This way not all switch ports get the carp traffic unless they participate in the multicast group. This cuts down on broadcast a lot. I recommend the HP switches, they have never given me any grief as long as I've worked with them. I even have a carp cluster spanning 2 building across the street over a fiber connection. It just works. If you need a managed switch on a budget I can confirm that the HP Procurve 1810-8G works well. It's web managed, supports vlans and basic traffic counters. It is also fanless. The smallest I have in use on a carp cluster is a Procurcve 2650 in combination with a 2900-48G. The biggest I have is a 8212zl. Do note that the software in the 1810 differs a lot from the other managed switches. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com mailto:support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com mailto:support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I've run a packet capture and here are the results: 1. Capture shows a bunch of VRRP announcements from the primary firewall to destination 224.0.0.18. The destination confirms this is a multicast address I believe. According to Wikipedia, VRRP and CARP share the same protocol number. So, I believe that these are CARP announcements. 2. All the VRRP requests had a vrrp.prio value of 0 with a description of Priority: 0 (Current Master has stopped participating in VRRP) 3. Over a 114 second capture, there were no VRRP announcements from the secondary firewall. 4. There were lots of ARP broadcast requests from the secondary firewall asking for who has the IP of the default gateway. There were 0 ARP requests from the primary firewall during the capture period
Re: [pfSense Support] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/10/2011 2:43 AM, Seth Mos wrote: Op 10-2-2011 4:18, Vaughn L. Reid III schreef: 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). Yes, some switch support multicast filtering, I know from experience with HP switches that it works with the setting on. So I know they have it implemented correctly. This way not all switch ports get the carp traffic unless they participate in the multicast group. This cuts down on broadcast a lot. I recommend the HP switches, they have never given me any grief as long as I've worked with them. I even have a carp cluster spanning 2 building across the street over a fiber connection. It just works. If you need a managed switch on a budget I can confirm that the HP Procurve 1810-8G works well. It's web managed, supports vlans and basic traffic counters. It is also fanless. The smallest I have in use on a carp cluster is a Procurcve 2650 in combination with a 2900-48G. The biggest I have is a 8212zl. Do note that the software in the 1810 differs a lot from the other managed switches. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I've run a packet capture and here are the results: 1. Capture shows a bunch of VRRP announcements from the primary firewall to destination 224.0.0.18. The destination confirms this is a multicast address I believe. According to Wikipedia, VRRP and CARP share the same protocol number. So, I believe that these are CARP announcements. 2. All the VRRP requests had a vrrp.prio value of 0 with a description of Priority: 0 (Current Master has stopped participating in VRRP) 3. Over a 114 second capture, there were no VRRP announcements from the secondary firewall. 4. There were lots of ARP broadcast requests from the secondary firewall asking for who has the IP of the default gateway. There were 0 ARP requests from the primary firewall during the capture period. 5. There were lots of ICMP pings from both the primary and secondary Pfsense firewalls to the default gateway on this WAN interface. I assume this is from the Load Balance Fail-Over configuration I have enabled for the cluster on this interface. I confirmed that the Master firewall shows itself as Master for all interfaces. I confirmed that the Secondary firewall shows itself as Backup for all interfaces. - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/10/2011 9:32 AM, Vaughn L. Reid III wrote: On 2/10/2011 2:43 AM, Seth Mos wrote: Op 10-2-2011 4:18, Vaughn L. Reid III schreef: 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). Yes, some switch support multicast filtering, I know from experience with HP switches that it works with the setting on. So I know they have it implemented correctly. This way not all switch ports get the carp traffic unless they participate in the multicast group. This cuts down on broadcast a lot. I recommend the HP switches, they have never given me any grief as long as I've worked with them. I even have a carp cluster spanning 2 building across the street over a fiber connection. It just works. If you need a managed switch on a budget I can confirm that the HP Procurve 1810-8G works well. It's web managed, supports vlans and basic traffic counters. It is also fanless. The smallest I have in use on a carp cluster is a Procurcve 2650 in combination with a 2900-48G. The biggest I have is a 8212zl. Do note that the software in the 1810 differs a lot from the other managed switches. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I've run a packet capture and here are the results: 1. Capture shows a bunch of VRRP announcements from the primary firewall to destination 224.0.0.18. The destination confirms this is a multicast address I believe. According to Wikipedia, VRRP and CARP share the same protocol number. So, I believe that these are CARP announcements. 2. All the VRRP requests had a vrrp.prio value of 0 with a description of Priority: 0 (Current Master has stopped participating in VRRP) 3. Over a 114 second capture, there were no VRRP announcements from the secondary firewall. 4. There were lots of ARP broadcast requests from the secondary firewall asking for who has the IP of the default gateway. There were 0 ARP requests from the primary firewall during the capture period. 5. There were lots of ICMP pings from both the primary and secondary Pfsense firewalls to the default gateway on this WAN interface. I assume this is from the Load Balance Fail-Over configuration I have enabled for the cluster on this interface. I confirmed that the Master firewall shows itself as Master for all interfaces. I confirmed that the Secondary firewall shows itself as Backup for all interfaces. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I performed a second capture of 3 minutes on malfunctioning WAN and noted identical results for the VRRP/CARP packets. On the second capture, however, I did see ARP requests from both firewalls asking for the MAC of the IP of the Default Gateway -- this was different from my item number 4 in the previous post. I also performed a 3 minute packet capture from one of the known working WAN connections on the cluster. The VRRP packets on that connection showed an origination address of the Real IP on primary/Master firewall and a multi-cast destination, just like the results from the problem WAN connection. I also noted that the vrrp.prio value and description was the same on the working WAN as on the not-working WAN. Both the working WAN connection packet capture and the non-Working WAN packet captures show IGMP packets noting the entering and leaving of multi-cast groups. - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/10/2011 10:42 AM, Vaughn L. Reid III wrote: On 2/10/2011 9:32 AM, Vaughn L. Reid III wrote: On 2/10/2011 2:43 AM, Seth Mos wrote: Op 10-2-2011 4:18, Vaughn L. Reid III schreef: 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). Yes, some switch support multicast filtering, I know from experience with HP switches that it works with the setting on. So I know they have it implemented correctly. This way not all switch ports get the carp traffic unless they participate in the multicast group. This cuts down on broadcast a lot. I recommend the HP switches, they have never given me any grief as long as I've worked with them. I even have a carp cluster spanning 2 building across the street over a fiber connection. It just works. If you need a managed switch on a budget I can confirm that the HP Procurve 1810-8G works well. It's web managed, supports vlans and basic traffic counters. It is also fanless. The smallest I have in use on a carp cluster is a Procurcve 2650 in combination with a 2900-48G. The biggest I have is a 8212zl. Do note that the software in the 1810 differs a lot from the other managed switches. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I've run a packet capture and here are the results: 1. Capture shows a bunch of VRRP announcements from the primary firewall to destination 224.0.0.18. The destination confirms this is a multicast address I believe. According to Wikipedia, VRRP and CARP share the same protocol number. So, I believe that these are CARP announcements. 2. All the VRRP requests had a vrrp.prio value of 0 with a description of Priority: 0 (Current Master has stopped participating in VRRP) 3. Over a 114 second capture, there were no VRRP announcements from the secondary firewall. 4. There were lots of ARP broadcast requests from the secondary firewall asking for who has the IP of the default gateway. There were 0 ARP requests from the primary firewall during the capture period. 5. There were lots of ICMP pings from both the primary and secondary Pfsense firewalls to the default gateway on this WAN interface. I assume this is from the Load Balance Fail-Over configuration I have enabled for the cluster on this interface. I confirmed that the Master firewall shows itself as Master for all interfaces. I confirmed that the Secondary firewall shows itself as Backup for all interfaces. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I performed a second capture of 3 minutes on malfunctioning WAN and noted identical results for the VRRP/CARP packets. On the second capture, however, I did see ARP requests from both firewalls asking for the MAC of the IP of the Default Gateway -- this was different from my item number 4 in the previous post. I also performed a 3 minute packet capture from one of the known working WAN connections on the cluster. The VRRP packets on that connection showed an origination address of the Real IP on primary/Master firewall and a multi-cast destination, just like the results from the problem WAN connection. I also noted that the vrrp.prio value and description was the same on the working WAN as on the not-working WAN. Both the working WAN connection packet capture and the non-Working WAN packet captures show IGMP packets noting the entering and leaving of multi-cast groups. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org One more thing. If I unplug the connection that leads to the ISP's black box from the switch and leave everything else in place, pings from the secondary/backup firewall to the CARP start working as expected. I'm not sure I understand this behavior. With 2 IP addresses on the same subnet that can communicate with each other on the same VLAN of a switch, it seems to me that it shouldn't matter what else I plug into that switch (as long as it has a different IP and as long as it is not doing some
Re: [pfSense Support] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/10/2011 12:57 PM, Evgeny Yurchenko wrote: On 11-02-10 11:07 AM, Vaughn L. Reid III wrote: On 2/10/2011 10:42 AM, Vaughn L. Reid III wrote: On 2/10/2011 9:32 AM, Vaughn L. Reid III wrote: On 2/10/2011 2:43 AM, Seth Mos wrote: Op 10-2-2011 4:18, Vaughn L. Reid III schreef: 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). Yes, some switch support multicast filtering, I know from experience with HP switches that it works with the setting on. So I know they have it implemented correctly. This way not all switch ports get the carp traffic unless they participate in the multicast group. This cuts down on broadcast a lot. I recommend the HP switches, they have never given me any grief as long as I've worked with them. I even have a carp cluster spanning 2 building across the street over a fiber connection. It just works. If you need a managed switch on a budget I can confirm that the HP Procurve 1810-8G works well. It's web managed, supports vlans and basic traffic counters. It is also fanless. The smallest I have in use on a carp cluster is a Procurcve 2650 in combination with a 2900-48G. The biggest I have is a 8212zl. Do note that the software in the 1810 differs a lot from the other managed switches. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I've run a packet capture and here are the results: 1. Capture shows a bunch of VRRP announcements from the primary firewall to destination 224.0.0.18. The destination confirms this is a multicast address I believe. According to Wikipedia, VRRP and CARP share the same protocol number. So, I believe that these are CARP announcements. 2. All the VRRP requests had a vrrp.prio value of 0 with a description of Priority: 0 (Current Master has stopped participating in VRRP) 3. Over a 114 second capture, there were no VRRP announcements from the secondary firewall. 4. There were lots of ARP broadcast requests from the secondary firewall asking for who has the IP of the default gateway. There were 0 ARP requests from the primary firewall during the capture period. 5. There were lots of ICMP pings from both the primary and secondary Pfsense firewalls to the default gateway on this WAN interface. I assume this is from the Load Balance Fail-Over configuration I have enabled for the cluster on this interface. I confirmed that the Master firewall shows itself as Master for all interfaces. I confirmed that the Secondary firewall shows itself as Backup for all interfaces. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I performed a second capture of 3 minutes on malfunctioning WAN and noted identical results for the VRRP/CARP packets. On the second capture, however, I did see ARP requests from both firewalls asking for the MAC of the IP of the Default Gateway -- this was different from my item number 4 in the previous post. I also performed a 3 minute packet capture from one of the known working WAN connections on the cluster. The VRRP packets on that connection showed an origination address of the Real IP on primary/Master firewall and a multi-cast destination, just like the results from the problem WAN connection. I also noted that the vrrp.prio value and description was the same on the working WAN as on the not-working WAN. Both the working WAN connection packet capture and the non-Working WAN packet captures show IGMP packets noting the entering and leaving of multi-cast groups. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org One more thing. If I unplug the connection that leads to the ISP's black box from the switch and leave everything else in place, pings from the secondary/backup firewall to the CARP start working as expected. I'm not sure I understand this behavior. With 2 IP addresses on the same subnet that can communicate with each other on the same VLAN of a switch, it seems to me that it shouldn't matter what
Re: [pfSense Support] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/10/2011 7:30 PM, Moshe Katz wrote: Is your ISP Verizon? We have had many ARP issues with Verizon FIOS. For our pfSense box to get all of our IPs, we have to manually set each of the IPs as the WAN IP (one by one), then set up the Virtual IP settings after we do that. Moshe -- Moshe Katz -- mo...@ymkatz.net mailto:mo...@ymkatz.net -- +1(301)867-3732 On Thu, Feb 10, 2011 at 7:19 PM, Vaughn L. Reid III vaughn_reid_...@elitemail.org mailto:vaughn_reid_...@elitemail.org wrote: On 2/10/2011 12:57 PM, Evgeny Yurchenko wrote: On 11-02-10 11:07 AM, Vaughn L. Reid III wrote: On 2/10/2011 10:42 AM, Vaughn L. Reid III wrote: On 2/10/2011 9:32 AM, Vaughn L. Reid III wrote: On 2/10/2011 2:43 AM, Seth Mos wrote: Op 10-2-2011 4:18, Vaughn L. Reid III schreef: 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). Yes, some switch support multicast filtering, I know from experience with HP switches that it works with the setting on. So I know they have it implemented correctly. This way not all switch ports get the carp traffic unless they participate in the multicast group. This cuts down on broadcast a lot. I recommend the HP switches, they have never given me any grief as long as I've worked with them. I even have a carp cluster spanning 2 building across the street over a fiber connection. It just works. If you need a managed switch on a budget I can confirm that the HP Procurve 1810-8G works well. It's web managed, supports vlans and basic traffic counters. It is also fanless. The smallest I have in use on a carp cluster is a Procurcve 2650 in combination with a 2900-48G. The biggest I have is a 8212zl. Do note that the software in the 1810 differs a lot from the other managed switches. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com mailto:support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com mailto:support-h...@pfsense.com Commercial support available - https://portal.pfsense.org I've run a packet capture and here are the results: 1. Capture shows a bunch of VRRP announcements from the primary firewall to destination 224.0.0.18. The destination confirms this is a multicast address I believe. According to Wikipedia, VRRP and CARP share the same protocol number. So, I believe that these are CARP announcements. 2. All the VRRP requests had a vrrp.prio value of 0 with a description of Priority: 0 (Current Master has stopped participating in VRRP) 3. Over a 114 second capture, there were no VRRP announcements from the secondary firewall. 4. There were lots of ARP broadcast requests from the secondary firewall asking for who has the IP of the default gateway. There were 0 ARP requests from the primary firewall during the capture period. 5. There were lots of ICMP pings from both
[pfSense Support] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
I've got a PfSense version 1.2.3 cluster at a Public Library customer connected to 6 WAN links. The first 5 are connected as VLANS through a TP-Link SL3428 switch then to an ISP provided Router (4 ATT ADSL links each with a Netopia ADSL router and a Fiber Link with a Cisco 2800 series router). These 5 WAN links are all configured identically (except for IP, etc.) and have worked beautifully for 2 or 3 years). The first 5 WAN's all go out the same Intel server interface. The 6th connection goes out a second Intel server interface (There are 6 physical Intel server gigabit interfaces on the machines all together -- 4 onboard plus 1 dual port PCI-X card). Illustration: WAN Connections 1 through 5 Pfsense Cluster --- VLAN Trunk --- TP-Link Managed Switch --- Switch Ports out to each Provider on a different VLAN's (port to provider in access mode not tagged) --- Provider's Router -- Internet Everything Works!!! WAN Connection 6 Pfsense cluster -- VLAN Trunk -- D-Link Managed Switch -- Switch Port out to the Provider (port to provider in access mode not tagged) Provider's On-Site Black Box/Fiber Converter (can't get any details about what's in it) -- Nothing!!! The Library has recently decided to replace the ADSL links with a fiber-to-your door Internet connection. For redundancy, I've set this up to run through a D-Link DGS 3200-10 managed switch. I this connection configured identically to the other 5 working connections except ISP specific things like netmask and IP address. I cannot, for the life of me, get this 6th connection to work correctly. I've been doing some troubleshooting for bit now and have noticed some items that might be helpful on this 6th WAN connection. Address Learning enabled on the Switch (default setting): 1. If I leave MAC address learning on on the D-Link switch, the Carp Master can ping its real IP address, can ping its CARP IP address, and can ping the fail-over PfSense 2. The fail-over Pfsense server can ping its own real IP, can ping the Carp Master's real IP, but cannot ping the CARP IP. 3. When I first boot the switch, I can usually ping the CARP IP from the fail-over box 1 time before pings start timing out. 4. From a remote location, I am able to ping the real IP of both boxes, but I cannot ping the CARP IP. 5. Both boxes can ping the ISP's default gateway. Address Learning disabled on the Switch: 1. Both PFSense boxes can ping each other, and both can ping the CARP IP. 2. Neither can ping the ISP's IP address. 3. From a remote location, I am unable to ping any of the boxes on the 6th ISP interface. I've tried this connection through the same switch without VLAN's enabled for this connection and still have no connectivity through this provider. If I plug in a laptop directly to the switch and use any of the 3 IP's in question, I have a good Internet connection. On the D-Link Switch, Spanning Tree is disabled. The ports containing the PFSense box links are tagged VLAN trunks with no untagged ports allowed. The port leading to the ISP is an untagged VLAN that is only a member of 1 VLAN. I know I could set this up without fussing with the VLANS, but I wanted to be consistent between the 2 switches. I believe this is a switch related issue and not a PFSense related issue directly. I am hesitant to run this connection through the other managed switch because I'm looking for redundancy. If anyone has any suggestions about where my problem may be, I'd really appreciate the help. Thanks! - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
According to page 15 of the reference manual address learning is: Enable or disable MAC address learning for the selected ports. When Enabled, destination and source MAC addresses are automatically listed in the forwarding table. When address learning is Disabled, MAC addresses must be manually entered into the forwarding table. This is sometimes done for reasons of security or efficiency. See the section on Forwarding/Filtering for information on entering MAC addresses into the forwarding table. The default setting is Enabled. One other thing. I need to note that I have dedicated a CARP interface on each Pfsense box connected to each over via a cross-over cable. On 2/9/2011 2:35 PM, e...@tm-k.com wrote: [snip] Address Learning enabled on the Switch (default setting): [snip] Can you briefly explain what 'address learning' is according to D-Link? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
My understanding of forwarding also was that address learning is a normal part of switch operation. But, I find it odd that turning that off lets the fail-over box ping the CARP IP on the primary box, with address learning on, I am unable to do that. A clarification about the Carp setup -- Each PfSense server has a dedicated interface connected to each other via a crossover cable. This is the interface that is configured to send and receive pfsync and its related traffic in the carp setup page. The firewall rules for this dedicated interface on each server are to allow all traffic on the interface. With a dedicated interface for the Carp related stuff to use, do the other interfaces still send and receive multi-cast pfsync traffic? On 2/9/2011 5:10 PM, David Newman wrote: On 2/9/11 1:12 PM, Vaughn L. Reid III wrote: According to page 15 of the reference manual address learning is: Enable or disable MAC address learning for the selected ports. When Enabled, destination and source MAC addresses are automatically listed in the forwarding table. When address learning is Disabled, MAC addresses must be manually entered into the forwarding table. This is sometimes done for reasons of security or efficiency. See the section on Forwarding/Filtering for information on entering MAC addresses into the forwarding table. The default setting is Enabled. This just means the switch dynamically learns the source MAC of each attached device. 99.999 percent of all switches on the market have dynamic MAC learning enabled. This isn't the problem. One other thing. I need to note that I have dedicated a CARP interface on each Pfsense box connected to each over via a cross-over cable. Sorry, I don't completely understand your CARP setup. I too use a crossover cable between pairs of boxes but that's for pfsync, not CARP. pfsync migrates table state between pf boxes; CARP is for redundant sharing of a virtual IP address among multiple pf boxes, and would be of little use on a network consisting of a crossover cable. IIRC CARP uses multicast addressing for its keepalive messages. You might also want to verify that the switch is configured to forward multicast. dn On 2/9/2011 2:35 PM, e...@tm-k.com wrote: [snip] Address Learning enabled on the Switch (default setting): [snip] Can you briefly explain what 'address learning' is according to D-Link? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/9/2011 9:20 PM, Evgeny Yurchenko wrote: On 2/9/2011 2:35 PM, e...@tm-k.com wrote: [snip] Address Learning enabled on the Switch (default setting): [snip] Can you briefly explain what 'address learning' is according to D-Link? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org On 11-02-09 04:12 PM, Vaughn L. Reid III wrote: According to page 15 of the reference manual address learning is: Enable or disable MAC address learning for the selected ports. When Enabled, destination and source MAC addresses are automatically listed in the forwarding table. When address learning is Disabled, MAC addresses must be manually entered into the forwarding table. This is sometimes done for reasons of security or efficiency. See the section on Forwarding/Filtering for information on entering MAC addresses into the forwarding table. The default setting is Enabled. One other thing. I need to note that I have dedicated a CARP interface on each Pfsense box connected to each over via a cross-over cable. Please do not top-post. So Address Learing should be enabled. 1) do you see one box as stand-by, another one as active in web-interface? 2) connect laptop instead of ISP's cable and run packet capture you should be able to see once a second carp-heartbeat (multicast mac + carp IP in destination field). If one pfSense shows Active, another one shows Stand-by and on the laptop you see heartbeat from only one (master) pfSense then you did not mess up with carp configuration and vlans on the switch. Evgeny. 1. All the Master and backup status notifications in the web interface on both PFSense boxes show the correct status 2. I'll do a packet capture tomorrow and see if the carp-heartbeat shows up I was unaware that any Carp related traffic passed between any of the interfaces except the one designated as the synchronization interface. I need to double-check the multi-cast configuration on the switch tomorrow also ( I think I have multi-cast enabled on the switch, but need to confirm that). - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - 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] CARP IP Not Registering MAC Address or Switch Disregarding CARP MAC Address -- Maybe???
On 2/9/2011 10:09 PM, Chris Buechler wrote: On Wed, Feb 9, 2011 at 8:51 PM, Vaughn L. Reid III vaughn_reid_...@elitemail.org wrote: My understanding of forwarding also was that address learning is a normal part of switch operation. But, I find it odd that turning that off lets the fail-over box ping the CARP IP on the primary box, with address learning on, I am unable to do that. A clarification about the Carp setup -- Each PfSense server has a dedicated interface connected to each other via a crossover cable. This is the interface that is configured to send and receive pfsync and its related traffic in the carp setup page. The firewall rules for this dedicated interface on each server are to allow all traffic on the interface. With a dedicated interface for the Carp related stuff to use, do the other interfaces still send and receive multi-cast pfsync traffic? No but they send the multicast CARP traffic on all interfaces where a CARP IP resides. Thanks for this clarification. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Possible DHCP Server Failover Error?
I have now had an unexpected dhcp server behavior occur twice on a pfsense cluster when a power supply has malfunctioned and caused one pfsense device to go offline. Here are the details. Hardware Setup: 2 Server grade servers running pfsense 1.2.3RC1 with Intel Nics, dual core processors with the smp pfsense kernel, and 4 gigabytes of RAM. Multiple WAN links using tagged VLAN's. Multiple LAN links using tagged VLAN's. CARP enabled. DHCP Server enabled on both firewalls with failover DHCP peer setup enabled. On each device, the failover peer in the DHCP server setup is the real interface IP for the other firewall on that particular interface. For example, on pfsense1 LAN interface, the failover DHCP peer is pfsense2 real LAN IP. On pfsense2 LAN, the failover DHCP peer is pfsense1 real LAN IP. These two machines usually operate with 4000 to 7000 total active states from 75 to 130 nodes on the LAN side at any given time. Normal DHCP Messages: During normal operation with both firewalls functioning, both devices show My State -- Normal and Peer State -- Normal in the DHCP Status page. Possible DHCP Error: When one of the pfsense firewalls goes off-line unexpectedly (e.g. due to power failure on one of the devices, etc.), the DHCP server on the remaining unit shows unexpected behavior. First, the status of the remaining DHCP server shows My State -- Communications Interrupted and Peer State -- Normal. Second, initially, DHCP leases renew, but seem to take much longer than normal to get served to clients. After a long period of having only one active firewall, however, DHCP leases seem to stop getting handed-out, or the client's dhcp acquisition process times out before the remaining firewall answers the DHCP request. -Vaughn Reid III - 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] Re: Intel Atom Install Trouble
I reset the jetway dual-core atom board's bios to optimized defaults. The board rebooted and worked like a charm. Thanks for everyone's help and advice. VRIII On 3/30/2009 6:44 PM, Dave Warren wrote: In message49d1326b.3050...@elitemail.org Vaughn L. Reid III vaughn_reid_...@elitemail.org was claimed to have wrote: I have a Intel Atom based board that I'm trying to get pfsense to install on. I can boot fine into safe mode but I get a panic message when I try the default boot config. I can reproduce this from both the pfsense ISO and after an actual install onto the hard drive. I'm trying to install 1.2.3 (downloaded today). This is a shot in the dark, but try resetting the BIOS to it's defaults and see if you've got any luck. I've got an Atom 330 based system (Sorry, I don't have the mobo or chipset details handy, beyond to say it's a Intel mobo) that panics during the install based on some combination of BIOS options that I don't entirely recall. I have reason to believe there are some ACPI issues but haven't had the time to track it down, but at this point if I disable ACPI I can't even boot the system, it locks immediately after the Highpoint driver (I don't use any Highpoint cards in this machine), and ACPI needs to be enabled for the system to even boot. Beyond the initial hardware configuration fun, it has been rock solid. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Intel Atom Install Trouble
I have a Intel Atom based board that I'm trying to get pfsense to install on. I can boot fine into safe mode but I get a panic message when I try the default boot config. I can reproduce this from both the pfsense ISO and after an actual install onto the hard drive. I'm trying to install 1.2.3 (downloaded today). I've searched both the forum and the support mailing list archives for kernel panic, intel atom, bootloader.conf, and mptable_walk_table but didn't receive any helpful results. A google search of the error message listed below shows several links that lead to a C programming language file called mptable.c Here's the message: panic mptable_walk_table: Unknown MP Config Entry 194 Here are the board's specs and hardware configuration: Jetway Manufacturer Intel Atom dual core 1.6 ghz processor 2 gigabytes RAM Sata Drive 3 realtek 8110 PCI NICs on daughter board 1 realtek 8119 PCI-Express onboard Nic -- disabled in bios Onboard Audio -- disabled in bios ACPI -- disabled in bios USB 2.0 -- disabled in bios Floppy Drive -- disabled in bios SATA Generation 1 -- forced in bios (the hard drive is only 1st generation hardware, but just to be sure) Does anyone have any suggestions that I might find helpful to get this system to boot the default pfsense? Thanks for your assistance. - 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] Intel Atom Install Trouble
Thanks for the link to the FreeBSD issue reporting article. Where do I find the bootloader arguments that are added to a safe mode pfsense boot versus a normal boot. I would like to play around with some bootloader options to see what, in particular, needs to be turned off to get the boot message. Chris Buechler wrote: On Mon, Mar 30, 2009 at 4:58 PM, Vaughn L. Reid III vaughn_reid_...@elitemail.org wrote: I have a Intel Atom based board that I'm trying to get pfsense to install on. I can boot fine into safe mode but I get a panic message when I try the default boot config. I can reproduce this from both the pfsense ISO and after an actual install onto the hard drive. Sounds like you've tried the usual. You'll probably have to report it to a FreeBSD list. See: http://doc.pfsense.org/index.php/Policy_on_FreeBSD_issues - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] WAN, VLANS on WAN, and RRD Graph Behavior Graph or Feature?
I have a pfsense router configured with the following WAN setup. It's running 1.2.2. Wan Physical Interface Contains: WAN is mapped to the default untagged interface (I know this isn't a completely normal setup with VLAN's also on the interface too, but it's a legacy setup I've inherited and am not currently able to change) WAN2 through WAN5 are mapped to 802.1q VLANS on this same physical interface With this configuration, I have noticed the following behavior when viewing traffic RRD graphs: The WAN interface in the RRD page shows the sum of all traffic on the actual physical interface, including the VLAN traffic. Each WAN interface VLAN shows only the traffic on that VLAN. Is this a bug, or is this expected behavior? Thanks, Vaughn Reid III - 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] WAN, VLANS on WAN, and RRD Graph Behavior Graph or Feature?
Thanks for the confirmation that I'm experiencing expected behavior. I thought that was the case, but I wanted to be sure. Vaughn III Chris Buechler wrote: On Wed, Mar 25, 2009 at 9:16 AM, Vaughn L. Reid III vaughn_reid_...@elitemail.org wrote: I have a pfsense router configured with the following WAN setup. It's running 1.2.2. Wan Physical Interface Contains: WAN is mapped to the default untagged interface (I know this isn't a completely normal setup with VLAN's also on the interface too, but it's a legacy setup I've inherited and am not currently able to change) WAN2 through WAN5 are mapped to 802.1q VLANS on this same physical interface With this configuration, I have noticed the following behavior when viewing traffic RRD graphs: The WAN interface in the RRD page shows the sum of all traffic on the actual physical interface, including the VLAN traffic. Each WAN interface VLAN shows only the traffic on that VLAN. Is this a bug, or is this expected behavior? Expected, there is no way to differentiate between tagged and untagged traffic. It's showing you the traffic that's passing over that interface, which includes the VLANs assigned as other interfaces. You shouldn't use the parent interface with VLANs (for reasons completely unrelated to this, and not product/vendor specific). I would plan to change that, or just live with the understanding that the parent interface will always have the sum of all VLAN traffic and that your network is possibly open to VLAN hopping from tagged to parent interface. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Policy Routing and Re-Direct Question
Hello, I have a policy routing and re-direct question. Is it possible in PFSense to do something like the following: A request comes to PFSense on the internal LAN interface on port 80 or port 443. Instead of passing this out WAN to the Internet, can the traffic, instead, be re-directed to a different port number of another internal machine (e.g. a proxy server or content filter)? Ascii art example: LAN Network Workstation port 80 or 443 request -- PFSense LAN interface -- internal PFSense rules, etc -- re-direct back out interface to 2nd Internal network machine which would then either serve the content or fetch it from the Internet I'm asking this to see if it is feasible to set up a traditional proxy server/content filter in a way to avoid having to configure proxy settings on each client machine. I'm also wanting to keep the proxying and content filtering off of the gateway routers. If it would make things easier, the 2nd machine could live on a different PFSense interface. Thanks for your help. Vaughn Reid III - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] spamd package
I have been successfully using the spamd package for about 2 weeks at one of my client sites, and it is working wonderfully. It has reduced the amount of spam that the site's email server was receiving from about 15000 per day to about 50 to 75 per day. I configured the package as follows: On the external spam data sources page, I have the following 2 items configured: provider: spamhaus type: blacklist provider method: url url: zen.spamhaus.org provider: uceprotect network type: blacklist provider method: file file: http://wget-mirrors.uceprotect.net/rbldnsd-all/dnsbl-1.uceprotect.net.gz On the white list tab, I have the client's local email server's IP address listed. I left the default configuration on the spamd settings tab. I am having excellent luck with this package running on a pair of firewalls using CARP. I manually replicated my settings on both boxes, and it successfully works during failover (although the settings and spam database don't replicate -- but that's a given with most of the add-on packages). I believe that you may be experiencing problems because you don't have your local email server white listed. Vaughn Reid III Michel Servaes wrote: Hi, I just tried to install spamd today, but it seems to block all my messages. I've waited 25 minutes, and still no mail arrives. I also tried to add some blacklist servers from the openbsd/spamd page, but it seems not to really work. It just kept three entries in the greylist, and nothing else passed into that list, nor anything went through the mailserver I entered as next MTA. When I telnetted into the SMTP port on my WAN side (from another location obviously), the SMTP HELO string came very slowly (but changing the value to '0' for the delay didn't make it faster). Where can I find good info on how to configure it basic... from that point I could maybe tweak a little, but a basic guideline would be great to start with. Kind regards, Michel - 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] spamd package
Gary, Thanks for the suggestion. My client is a not-for-profit library. They own the hardware. I provide consulting services/labor. So, I believe that their usage is appropriate. I do not sale pre-configured appliances. Gary Buckmaster wrote: Vaughn, You should re-visit the spamhaus terms of service for their Zen service. It is not free for commercial use as you are apparently doing. Otherwise, thank you for the feedback on the package. -Gary Vaughn L. Reid III wrote: I have been successfully using the spamd package for about 2 weeks at one of my client sites, and it is working wonderfully. It has reduced the amount of spam that the site's email server was receiving from about 15000 per day to about 50 to 75 per day. I configured the package as follows: On the external spam data sources page, I have the following 2 items configured: provider: spamhaus type: blacklist provider method: url url: zen.spamhaus.org provider: uceprotect network type: blacklist provider method: file file: http://wget-mirrors.uceprotect.net/rbldnsd-all/dnsbl-1.uceprotect.net.gz On the white list tab, I have the client's local email server's IP address listed. I left the default configuration on the spamd settings tab. I am having excellent luck with this package running on a pair of firewalls using CARP. I manually replicated my settings on both boxes, and it successfully works during failover (although the settings and spam database don't replicate -- but that's a given with most of the add-on packages). I believe that you may be experiencing problems because you don't have your local email server white listed. Vaughn Reid III Michel Servaes wrote: Hi, I just tried to install spamd today, but it seems to block all my messages. I've waited 25 minutes, and still no mail arrives. I also tried to add some blacklist servers from the openbsd/spamd page, but it seems not to really work. It just kept three entries in the greylist, and nothing else passed into that list, nor anything went through the mailserver I entered as next MTA. When I telnetted into the SMTP port on my WAN side (from another location obviously), the SMTP HELO string came very slowly (but changing the value to '0' for the delay didn't make it faster). Where can I find good info on how to configure it basic... from that point I could maybe tweak a little, but a basic guideline would be great to start with. Kind regards, Michel - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Ping
Try creating a firewall rule on the Wan interface to allow ICMP packets. Vaughn Anil Garg wrote: My ISP has created a CLAN for me with the following public address: xxx.xxx.xxx.64/27 Gateway for my pfsense is xxx.xxx.xxx.65 I have configured the pfsense to static IP of xxx.xxx.xxx.66/27 and given an gateway of xxx.xxx.xxx65 Everything works fine and I can VPN into xxx.xxx.xxx.66 But my router does not respond to the ping. Any suggestions? Thanks Anil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Carp Slave Internet Access Problem/Question
I have two pfSense boxes running a recent version of 1.2 RC3. Fail-over seems to work correctly when the master unit dies, and the master unit takes back over when it comes back online, so I figure most of my settings must be mostly correct (I followed the visual tutorial listed on the pfsense.com site). I do, however, seem to have one problem with the slave carp unit. When it is not the master unit, it does not have internet access. From the diagnostic ping page on the web configurator of the carp slave, I cannot ping a remote site and the list of addon packages for the unit do not show up. Also, Snort rules will not update. From the WAN side, I am able to ping the real IP of the carp slave, but cannot connect to it remotely (unless it is working as the master carp unit). I believe that my problem may be a NAT issue. I have advanced outbound NAT enabled and have the master unit configured to sync NAT with the slave. I have found, however, that if I create a manual rule on the slave unit that tells it to perform NAT for all traffic and to use the real WAN IP address that all Internet access for the carp slave is restored. As soon as I remove this rule and rely on the synced advanced outbound NAT rule that is replicated from the master unit, however, internet access to the slave unit dies. I am able to access the master unit from both the Carp Wan IP and from its real Wan IP, and everything seems to work correctly with it. Both machines have identical hardware. The advanced outbound NAT rule that is synced between the two units is as follows: Interface -- WAN Source -- any Source Port -- * Destination -- * Destination Port -- * NAT Address -- The Carp IP Address NAT Port -- * Static Port -- No I have searched the mailing list and the forum and the updated carp documentation on the pfsense documentation site, but I have not yet found an explanation for this problem. I appreciate any help that may be available. Thanks, Vaughn Reid III Indiana, USA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] dhcp failover--missing parameter in web interface?
Also, with all of the money that you can save on technician costs and hardware by implementing something like pfsense, you might be able to afford an additional layer of transparent firewalling or some other security hardware/software or redundancy that you might otherwise be unable to afford. -Vaughn Reid III LJ Rand wrote: Please note that this may not just be a matter of preference to have the second pfsense box designated as secondary dhcp server. I am also hoping it will resolve the issue I reported earlier of running out of free IPs from the dynamic range even before the stash is exhausted. I have completely abandoned using dynamic dhcp in my setup because of this outstanding issue--did not get resolved even after dhcpd package was updated to the latest version. Thanks. LJ - Original Message From: Scott Ullrich [EMAIL PROTECTED] To: support@pfsense.com Sent: Monday, July 9, 2007 5:30:42 PM Subject: Re: [pfSense Support] dhcp failover--missing parameter in web interface? On 7/9/07, LJ Rand [EMAIL PROTECTED] wrote: I am running 1.2-beta-1 snapshot 05-11-2007 on 2 pfsense firewalls carp'ed together. I configured dhcp server in failover mode for both firewalls, following instructions. I do not see on the web interface how to set the second firewall as secondary dhcp, so when I check the resultant /var/dhcpd/etc/dhcpd.conf file, both firewalls consider themselves as primary. My preference is for all clients to take their dhcp address configuration from the first firewall, and only contact the second firewall when the first one is down. I could manually edit above dhcpd.conf file, but I don't want to keep doing that everytime I reload the configuration. Would someone please look into this issue? Thanks. Woops, I misread this originally. Please ignore me. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - 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] I hit reply to the wrong post..... oops
Oops!!! I didn't realize I had jumped topics. :( Vaughn Reid III Vaughn L. Reid III wrote: Also, with all of the money that you can save on technician costs and hardware by implementing something like pfsense, you might be able to afford an additional layer of transparent firewalling or some other security hardware/software or redundancy that you might otherwise be unable to afford. -Vaughn Reid III LJ Rand wrote: Please note that this may not just be a matter of preference to have the second pfsense box designated as secondary dhcp server. I am also hoping it will resolve the issue I reported earlier of running out of free IPs from the dynamic range even before the stash is exhausted. I have completely abandoned using dynamic dhcp in my setup because of this outstanding issue--did not get resolved even after dhcpd package was updated to the latest version. Thanks. LJ - Original Message From: Scott Ullrich [EMAIL PROTECTED] To: support@pfsense.com Sent: Monday, July 9, 2007 5:30:42 PM Subject: Re: [pfSense Support] dhcp failover--missing parameter in web interface? On 7/9/07, LJ Rand [EMAIL PROTECTED] wrote: I am running 1.2-beta-1 snapshot 05-11-2007 on 2 pfsense firewalls carp'ed together. I configured dhcp server in failover mode for both firewalls, following instructions. I do not see on the web interface how to set the second firewall as secondary dhcp, so when I check the resultant /var/dhcpd/etc/dhcpd.conf file, both firewalls consider themselves as primary. My preference is for all clients to take their dhcp address configuration from the first firewall, and only contact the second firewall when the first one is down. I could manually edit above dhcpd.conf file, but I don't want to keep doing that everytime I reload the configuration. Would someone please look into this issue? Thanks. Woops, I misread this originally. Please ignore me. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - 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]
Re: [pfSense Support] VPN tunnel connects properly, but it frequently drops
I have a pfsense box with the June 30th snapshot, and have it connected to two Linksys RV016's, two Linksys RV082's, and two Hotbrick 800/2. The pfsense box has two adsl connections with static IP's for WAN connectivity, and the remote sites also have adsl connections. Both brands of units are running the most recent firmware posted on their vendor's web site as of June 29, 2007. I was consistently, having trouble with the VPN tunnels dropping after prolonged periods of inactivity. The remote endpoints had to actively look for items on the LAN behind the pfsense box to get the connection to re-establish. Sometimes, for example, if the WAN disconnected for some reason, the VPN's tunnels would not get re-built without rebooting the Linksys or Hotbrick router. Anyway, I contacted Hotbrick's tech support, and asked them for advice since they sell a couple other products that look to be customized and branded versions of pfsense. They sent me a link to one of their help documents here: http://www.hotbrick.com/support_detail.asp?tipo=4 Basically, the documents suggest the following settings for VPN's between Hotbrick products: IPSEC Phase 1: Negotiation: Main Encryption: 3DES Hash: SHA1 DH Key: 2 (1024 Bit) Lifetime: 28800 Authentication: Pre-Shared Key IPSEC Phase 2: Protocol: ESP Encryption: Make Sure 3DES only is checked Hash: SHA1 Perfect Forward Secrecy: 2 (1024 Bit) Lifetime: 28800 So, I have tried these settings on my remote endpoint Hotbrick's and Linksys's and have experienced much more stable VPN connections. I have also noticed that the VPN connection doesn't have to be re-established by the remote endpoint after long periods of inactivity, and I have noticed that the tunnels seem to rebuild correctly after a WAN link goes down and then comes back up. Also, on the Linksys devices I have dead peer detection turned off, but have keep-alive turned on. On the pfsense box, I have the IP address listed to ping as an IP on the remote subnet that is not assigned to any host. I found that on the Hotbrick and the Linksys units that long term pinging of the remote LAN gateway (i.e. pinging the LAN IP of the linksys or hotbrick unit) caused the device to actively start blocking the connection from the pfsense box. -Vaughn Reid III David Strout wrote: I have had the same experience w/ the RV016 and pfSense. What is the exact version on the linksys side (have you upgraded the firmware to the current?), and what build of 1.0.1 pfSense are you running? I'd move the the current 1.2-BETA SNAP and upgrade your Linksys to the current 2.0.17. I personally have had very little luck in conecting linksys to anything but linksys for VPN connectivity. I have gotten it to work in the lab and maintain it's stability but under a high load situation it becomes very unstable and drops quite often. Hi, I have PFSense 1.0.1 version configured with open VPN on one site and Dual wan router (Linksys RV016) configured on the other site. VPN connection works fine. However, even though both the routers are configured to be on a Keep Alive status in reference to the VPN connectivity, still the VPN connection drops consistently. Please let me know for any further details you want from me to resolve this issue. Any help from your side would really be appreciated. Thanks Regards, Vidit Gupta - 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] VPN tunnel connects properly, but it frequently drops
That is true. I believe, however, that their 6000 and 4000 series are, perhaps, pfsense based. Vaughn III Pedro Paulo Oliveira Jr wrote: Hotbrick VPN800/2 is not based on pfsense. -Original Message- From: Vaughn L. Reid III [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 2 de julho de 2007 08:55 To: support@pfsense.com Subject: Re: [pfSense Support] VPN tunnel connects properly, but it frequently drops I have a pfsense box with the June 30th snapshot, and have it connected to two Linksys RV016's, two Linksys RV082's, and two Hotbrick 800/2. The pfsense box has two adsl connections with static IP's for WAN connectivity, and the remote sites also have adsl connections. Both brands of units are running the most recent firmware posted on their vendor's web site as of June 29, 2007. I was consistently, having trouble with the VPN tunnels dropping after prolonged periods of inactivity. The remote endpoints had to actively look for items on the LAN behind the pfsense box to get the connection to re-establish. Sometimes, for example, if the WAN disconnected for some reason, the VPN's tunnels would not get re-built without rebooting the Linksys or Hotbrick router. Anyway, I contacted Hotbrick's tech support, and asked them for advice since they sell a couple other products that look to be customized and branded versions of pfsense. They sent me a link to one of their help documents here: http://www.hotbrick.com/support_detail.asp?tipo=4 Basically, the documents suggest the following settings for VPN's between Hotbrick products: IPSEC Phase 1: Negotiation: Main Encryption: 3DES Hash: SHA1 DH Key: 2 (1024 Bit) Lifetime: 28800 Authentication: Pre-Shared Key IPSEC Phase 2: Protocol: ESP Encryption: Make Sure 3DES only is checked Hash: SHA1 Perfect Forward Secrecy: 2 (1024 Bit) Lifetime: 28800 So, I have tried these settings on my remote endpoint Hotbrick's and Linksys's and have experienced much more stable VPN connections. I have also noticed that the VPN connection doesn't have to be re-established by the remote endpoint after long periods of inactivity, and I have noticed that the tunnels seem to rebuild correctly after a WAN link goes down and then comes back up. Also, on the Linksys devices I have dead peer detection turned off, but have keep-alive turned on. On the pfsense box, I have the IP address listed to ping as an IP on the remote subnet that is not assigned to any host. I found that on the Hotbrick and the Linksys units that long term pinging of the remote LAN gateway (i.e. pinging the LAN IP of the linksys or hotbrick unit) caused the device to actively start blocking the connection from the pfsense box. -Vaughn Reid III David Strout wrote: I have had the same experience w/ the RV016 and pfSense. What is the exact version on the linksys side (have you upgraded the firmware to the current?), and what build of 1.0.1 pfSense are you running? I'd move the the current 1.2-BETA SNAP and upgrade your Linksys to the current 2.0.17. I personally have had very little luck in conecting linksys to anything but linksys for VPN connectivity. I have gotten it to work in the lab and maintain it's stability but under a high load situation it becomes very unstable and drops quite often. Hi, I have PFSense 1.0.1 version configured with open VPN on one site and Dual wan router (Linksys RV016) configured on the other site. VPN connection works fine. However, even though both the routers are configured to be on a Keep Alive status in reference to the VPN connectivity, still the VPN connection drops consistently. Please let me know for any further details you want from me to resolve this issue. Any help from your side would really be appreciated. Thanks Regards, Vidit Gupta - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Questions about Full Version versus Embedded
I have a few questions about Pfsense full versus Pfsense embedded. 1. What, specifically, are the differences between the full and embedded versions? Are there features available in one that is not available in the other? Do they both support the same hardware? 2. Do both the embedded and full version write their log files to memory? 3. Is it suitable to use the full version on a disk on module or micro drive if I have a big enough solid state storage device? 4. How do I update the embedded version? Do I just download and install the files listed under update? 5. What are the advantages and disadvantages of the full and embedded versions? I appreciate any answers or links that you may be willing to provide. I'm asking because I'm wondering if it is feasible or even a good idea to replace the small ide hard drives on some of my customers pfsense boxes with 1 or 2 gig disk on module solid state media. Thanks, Vaugh Reid III - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] Questions about Full Version versus Embedded
If I understand you correctly then the embedded version does not support the addition of packages and does not write to disk during runtime operations. The full version, on the other hand, supports the addition of packages and definitely writes to disk during runtime operation. Are these the major differences between the two versions? --Vaughn On Tue, 1 May 2007 14:41:50 -0400, Sean Cavanaugh [EMAIL PROTECTED] said: the embedded version is designed for a system that's running off of Compact flash such as the WRAP and Soekris platforms so it does not write anything to storage during runtime other than config changes. logs and whatnot are (supposedly) written to a RAM temp location. think of it more like the firmware that's running on a linksys router. the full version is designed for full servers with storage that's not limited by how many writes it can do (flash, HDD, etc) and as such will record logs to storage as well as support adding packages to extend the functionality of the firewall. this would be more of a full software firewall running on something like a 2U server from Dell or something. -Sean Cavanaugh From: [EMAIL PROTECTED] To: support@pfsense.com Date: Tue, 1 May 2007 14:34:00 -0400 Subject: [pfSense Support] Questions about Full Version versus Embedded I have a few questions about Pfsense full versus Pfsense embedded. 1. What, specifically, are the differences between the full and embedded versions? Are there features available in one that is not available in the other? Do they both support the same hardware? 2. Do both the embedded and full version write their log files to memory? 3. Is it suitable to use the full version on a disk on module or micro drive if I have a big enough solid state storage device? 4. How do I update the embedded version? Do I just download and install the files listed under update? 5. What are the advantages and disadvantages of the full and embedded versions? I appreciate any answers or links that you may be willing to provide. I'm asking because I'm wondering if it is feasible or even a good idea to replace the small ide hard drives on some of my customers pfsense boxes with 1 or 2 gig disk on module solid state media. Thanks, Vaugh Reid III - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+worldmkt=en-USform=QBRE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Wireless 3g Cellular PC Card Modem Support on Pfsense
My local Fire Dept has asked me about the feasibility of building them a dual Wan Pfsense box using two Internet Access provided by two accounts to Verizon's wireless cellular broadband service. Does Pfsense provide support for any cellular modems? Do any of the pfsense resellers, support organizations provide a ready-made product that might match this description? Thanks, Vaughn Reid III - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Wireless 3g Cellular PC Card Modem Support on Pfsense
Thanks for the info. I was just wondering at this point. I had a fire dept ask me about the feasibility because of interest on their part about using a multi-wan firewall deployed with their command vehicle to establish a mobile and somewhat fast Internet gateway that could easily be deployed on the scene of a large fire, or other emergency. My immediate thought was a multi-wan cellular broadband powered embedded fanless firewall with wireless card and hi-gain antenna for a quick fix network in a box that could provide an emergency worker hotspot with internet and VPN capabilities back to the home network and resources. At this point, satellite is not an option for them, but they have a couple mobile cellular accounts. A couple questions, how large of a bounty would be required, and are there any other products out there that can currently use multiple cellular broadband modems as wan connections? (I'm aware of the dlink 3g routers and one from Linksys). Hmmm. I suppose that I could get a couple dlinks and place them in bridge mode to a pfsense box. Just thinking out loud at this point. --Vaughn On Tue, 01 May 2007 16:47:41 -0400, Chris Buechler [EMAIL PROTECTED] said: Vaughn L. Reid III wrote: My local Fire Dept has asked me about the feasibility of building them a dual Wan Pfsense box using two Internet Access provided by two accounts to Verizon's wireless cellular broadband service. Does Pfsense provide support for any cellular modems? Do any of the pfsense resellers, support organizations provide a ready-made product that might match this description? No and no. If you have some external device that can turn the cell connection into an Ethernet connection, that'll work. No cell services are supported at this time. I have a Verizon EVDO PC card for my laptop, but with a 15 Mb cable modem and 3.5 Mb DSL line at home, I have no interest in making it work with pfsense other than curiosity, which means it'll be a long time before I have time to mess with it. If you'd like, start a bounty and you may be able to adjust my priorities. :) - 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] Wireless 3g Cellular PC Card Modem Support on Pfsense
Cool, thanks for the links. I'll check out the Soekris list too. Vaughn :-) RB wrote: A couple of potential options - we just chased a similar rabbit over on the Soekris list, and I got a lot of good links out of it: http://www.digi.com/products/cellulargateways/digiconnectwanfamily.jsp http://www.digi.com/products/cellulargateways/connectportwanvpn.jsp http://www.novatelwireless.com/products/ovation/mcu2000.html http://www.sierrawireless.com/product/mp875gps.aspx Some of them do everything you want; others may need an embedded pfSense device involved, others may need 'modem' support. RB - 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] help pptp plz
I have PPTP successfully working on my pfsense box. Here's how I got stuff working. 1. My lan IP is 192.168.10.1/24, and my Lan net is 192.168.10.0/24 2. On the VPN PPTP page, I selected the radio button that corresponds to Enable PPTP Server 3. My PPTP server address is: 192.168.150.25 4. My Remote Address Range is: 192.168.150.48/28 -- The /28 was already entered. You can change this netmask, but you need to do it manually through config files -- Check out the forum for more info. 5. I also have the Require 128-bit Encryption option selected. 6. After selecting these settings, I clicked save. Next, on the Users tab of the VPN PPTP page I created usernames and passwords for the various accounts that I wanted to allow access to the pfsense's PPTP server. I did not add any special routes or other items to to the pfsense box's configuration. It just worked like magic. I have successfully connected to the network using pptp by using the VPN wizard on both Windows 2000 and Windows XP Pro road warriors. I am running the PPTP server on the snapshot built: *1.0.1-SNAPSHOT-03-27-2007 * built on Sun Apr 8 18:57:04 EDT 2007 When I first started using pfsense, however, I did notice that I had trouble with getting PPTP to work on the 1.0.1 default release. As soon as I updated to a snapshot release, however, my problems in this area went away. Vaughn Reid III Arthur Mitchell wrote: how do i add an static routes? - Original Message - From: Holger Bauer [EMAIL PROTECTED] To: support@pfsense.com Sent: Tuesday, April 17, 2007 8:13 AM Subject: RE: [pfSense Support] help pptp plz You do not need to forward anything. When your users connect they will become part of your local network. However as you have chosen different networks for the PPTP Clients and LAN (unless I have some misinterpretation here) you have to make sure your PPTP Clients use the remote subnets gateway as default gateway or you need to add static routes at the client (Windows XP and Mac OS X default to this setting btw). Also make sure you have firewallrules at firewallrules, pptp that allow the desired traffic. Holger From: Arthur Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 7:12 AM To: support@pfsense.com Subject: [pfSense Support] help pptp plz Hi i have a problem with pfsense. I have configured the pptp server and it's working fine. on the pptp server side the add is 192.168.16.1 that is the server's add ofer pptp. I want to portfoward that add (192.168.16.1) to a lan add on my network (192.168.1.5) that is my fileserver add that others must have acsess to. plz help me im in the dark about this. Arthur Mitchell Virus checked by G DATA AntiVirusKit Version: AVK 17.4036 from 17.04.2007 Virus news: www.antiviruslab.com - 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]
Re: [pfSense Support] help pptp plz
Sorry for the confusion, I should have been slightly more explicit in my previous reply. I was trying to explain that, on my pfsense box, I have allow everything from everywhere to everywhere on my PPTP interface in the firewall rules. On my machine, I know that I have this type of setup because a * symbol appears in each of the fields: Proto Source PortDestination PortGateway Schedule Vaughn On Tue, 17 Apr 2007 16:54:00 +0200, Rainer Duffner [EMAIL PROTECTED] said: Arthur Mitchell wrote: what is asterisks? http://en.wikipedia.org/wiki/Asterisk ;-) cheers, Rainer - 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] help pptp plz
I forgot one step in the process. Go to firewall rules and make sure that there are asterisks all the way across for the pptp VPN interface (unless you want to do some filtering). Vaughn Arthur Mitchell wrote: still got a problem it doesnt become a part of my local network when i want to acc a machine on my network it isnt there and the ip is rejected - Original Message - From: Vaughn L. Reid III [EMAIL PROTECTED] To: support@pfsense.com Sent: Tuesday, April 17, 2007 12:28 PM Subject: Re: [pfSense Support] help pptp plz I have PPTP successfully working on my pfsense box. Here's how I got stuff working. 1. My lan IP is 192.168.10.1/24, and my Lan net is 192.168.10.0/24 2. On the VPN PPTP page, I selected the radio button that corresponds to Enable PPTP Server 3. My PPTP server address is: 192.168.150.25 4. My Remote Address Range is: 192.168.150.48/28 -- The /28 was already entered. You can change this netmask, but you need to do it manually through config files -- Check out the forum for more info. 5. I also have the Require 128-bit Encryption option selected. 6. After selecting these settings, I clicked save. Next, on the Users tab of the VPN PPTP page I created usernames and passwords for the various accounts that I wanted to allow access to the pfsense's PPTP server. I did not add any special routes or other items to to the pfsense box's configuration. It just worked like magic. I have successfully connected to the network using pptp by using the VPN wizard on both Windows 2000 and Windows XP Pro road warriors. I am running the PPTP server on the snapshot built: *1.0.1-SNAPSHOT-03-27-2007 * built on Sun Apr 8 18:57:04 EDT 2007 When I first started using pfsense, however, I did notice that I had trouble with getting PPTP to work on the 1.0.1 default release. As soon as I updated to a snapshot release, however, my problems in this area went away. Vaughn Reid III Arthur Mitchell wrote: how do i add an static routes? - Original Message - From: Holger Bauer [EMAIL PROTECTED] To: support@pfsense.com Sent: Tuesday, April 17, 2007 8:13 AM Subject: RE: [pfSense Support] help pptp plz You do not need to forward anything. When your users connect they will become part of your local network. However as you have chosen different networks for the PPTP Clients and LAN (unless I have some misinterpretation here) you have to make sure your PPTP Clients use the remote subnets gateway as default gateway or you need to add static routes at the client (Windows XP and Mac OS X default to this setting btw). Also make sure you have firewallrules at firewallrules, pptp that allow the desired traffic. Holger From: Arthur Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 7:12 AM To: support@pfsense.com Subject: [pfSense Support] help pptp plz Hi i have a problem with pfsense. I have configured the pptp server and it's working fine. on the pptp server side the add is 192.168.16.1 that is the server's add ofer pptp. I want to portfoward that add (192.168.16.1) to a lan add on my network (192.168.1.5) that is my fileserver add that others must have acsess to. plz help me im in the dark about this. Arthur Mitchell Virus checked by G DATA AntiVirusKit Version: AVK 17.4036 from 17.04.2007 Virus news: www.antiviruslab.com - 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] - 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] IPSEC over an OPT interface Problems
I just wanted to report an update of how my IPSEC over OPTx is working. It's been a few days, now since I set up the manual rules on the OPTx interface that I wanted to use for IPSEC. Since I set up the rules listed in my previous post, my IPSEC VPN's over the OPTx interface are working well and seem very stable. Vaughn Vaughn L. Reid III wrote: Just to be thorough, I added two more rules to the firewall's OPT interface to make sure all the IPSEC stuff gets through. I'm fuzzy on if the last two are needed, but just to be safe, I added them. Here are all the rule that I've added: Rules in the format listed below: Format: Protocol Source Port Destination Port Gateway Schedule 1. UDP * * Interface IP Address 500 * Blank 2. ESP * * Interface IP Address * * Blank 3. AH * * Interface IP Address * * Blank 4. GRE * * Interface IP Address * * Blank Vaughn On Mon, 02 Apr 2007 20:43:38 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: Interesting, This version of the firmware doesn't even list the VPN tunnel that is configured for the OPT interface in the vpn section of /tmp/rules.debug. The tunnel definition is listed in the GUI, and it's working with the manual rules because I'm in the process of accessing remote resources now. In /tmp/rules.debug, however, it's like the vpn out the opt interface just doesn't exist. I checked the firewall rules section of /tmp/rules.debug, and the manual rules that I added are there. Also, the firmware version that I was using when I started this thread last week showed the VPN tunnel definition in /tmp/rules.debug, but it showed the wrong interface. Vaughn On Mon, 2 Apr 2007 20:32:47 -0400, Scott Ullrich [EMAIL PROTECTED] said: On 4/2/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Here are the rules for the interface in question that seem to make the IPSEC tunnel work: [snip] Look in /tmp/rules.debug and search for IPSEC. Do you see rules permitting traffic to the interface? Scott - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC over an OPT interface Problems
No. The only things that I added/changed were the firewall rules. Actually, I don't have manually entered static routes configured for any of my IPSEC connections, and they all work. When I pull up the routing table, I have noticed that the pfsense box appears to automatically add the routes. Vaughn [EMAIL PROTECTED] wrote: Do you have static routes set up as well? I just wanted to report an update of how my IPSEC over OPTx is working. It's been a few days, now since I set up the manual rules on the OPTx interface that I wanted to use for IPSEC. Since I set up the rules listed in my previous post, my IPSEC VPN's over the OPTx interface are working well and seem very stable. Vaughn Vaughn L. Reid III wrote: Just to be thorough, I added two more rules to the firewall's OPT interface to make sure all the IPSEC stuff gets through. I'm fuzzy on if the last two are needed, but just to be safe, I added them. Here are all the rule that I've added: Rules in the format listed below: Format: Protocol Source Port Destination Port Gateway Schedule 1. UDP * * Interface IP Address 500 * Blank 2. ESP * * Interface IP Address * * Blank 3. AH * * Interface IP Address * * Blank 4. GRE * * Interface IP Address * * Blank Vaughn - 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] IPSEC over an OPT interface Problems
I should also add, in case it matters that all of the remote end-points are either Linksys RV082's, Linksys RV016's, Hotbrick 800/2's, or Netgear FVS338's. All of the remote end-points are configured with static IP's and any ISP supplied routers are configured solely as bridge devices. If PPPoE is being used, I have the remote Linksys, Netgear, or Hotbrick performing the PPPoE. These remote end points operate over a combination of Cable, ADSL, and wireless Internet access from their various ISP's. I have learned that, if the ISP's supplied router/firewall is doing any sort of NAT or port forwarding, it just kills IPSEC VPN stability. This seems especially true for the Linksys and Netgear devices that I've run across. Vaughn Vaughn L. Reid III wrote: No. The only things that I added/changed were the firewall rules. Actually, I don't have manually entered static routes configured for any of my IPSEC connections, and they all work. When I pull up the routing table, I have noticed that the pfsense box appears to automatically add the routes. Vaughn [EMAIL PROTECTED] wrote: Do you have static routes set up as well? I just wanted to report an update of how my IPSEC over OPTx is working. It's been a few days, now since I set up the manual rules on the OPTx interface that I wanted to use for IPSEC. Since I set up the rules listed in my previous post, my IPSEC VPN's over the OPTx interface are working well and seem very stable. Vaughn Vaughn L. Reid III wrote: Just to be thorough, I added two more rules to the firewall's OPT interface to make sure all the IPSEC stuff gets through. I'm fuzzy on if the last two are needed, but just to be safe, I added them. Here are all the rule that I've added: Rules in the format listed below: Format: Protocol Source Port Destination Port Gateway Schedule 1. UDP * * Interface IP Address 500 * Blank 2. ESP * * Interface IP Address * * Blank 3. AH * * Interface IP Address * * Blank 4. GRE * * Interface IP Address * * Blank Vaughn - 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]
Re: [pfSense Support] OK, I think this is simple...
I have a customer with a setup that sounds very similar to what you are
describing. They have 2 WAN type connections. The first is an SDSL
line that is used for IPSEC and other general WAN stuff. The second is
an ADSL line that they use to feed their proxy server/content filter.
They don't have any load balancing or failover setup. They do, however,
have a single rule in their firewall config that directs all traffic
from the content filter to use the ADSL connection.
In order to set this up correctly for them, I first read the information
available here:
http://www.pfsense.com/mirror.php?section=tutorials/policybased_multiwan/policybased_multiwan.pdf
Then, I set up the following rule on the LAN interface protocol page:
Proto -- *
Source -- Lan IP of Proxy/content filter
Destination -- *
Port -- *
Gateway -- The Default Gateway of the ADSL connection -- Note: This is
the actual ADSL interface's gateway, not the IP of the ADSL interface
itself.
All the proxy server's Internet traffic now goes out through the ADSL
interface. Even cooler that that, when the remote VPN'd sites request
stuff from the proxy, the firewall is smart enough to allow the proxy
server to answer back to the remote sites via the VPN interface (which
is WAN, not ADSL). Hope this helps.
Vaughn Reid III
Robert Goley wrote:
Just leave off the steps for creating the pools and skip straight to setting
your LAN rules. All you should have to do to send the traffic for the one
application is define a couple of rules based on either source IP on the LAN,
Destination IP, or destination ports that application uses. you will set
these rules to the gateway of your OPT1 connection. This rule will need to
be higher in the list than the default traffic rule. Leave the default
traffic rule set to the gateway of your WAN connection.
Robert
On Thursday 05 April 2007 18:06, Jaye Mathisen wrote:
Yeah, I read that. But I don't want load balancing or failover.
Logging in via shell shows the routing is set right, in that the
default route is still WAN.
# netstat -rn
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default70.58.179.174 UGS 0 837 sis0
I created an OPT1 interface, set it to DHCP. Went to firewall rules
and added a rule that sent proto:any, source:*, Port*, dest 4.2.2.2,
port *, Gateway OPT1.
# User-defined rules follow
pass in quick on $lan from 192.168.0.0/24 to any keep state label
USER_RULE: D efault LAN - any
pass in log quick on $lan route-to ( sis2 192.168.100.1 ) from any to {
4.2.2. 2 } keep state label USER_RULE
But all traffic is now going out the OPT1 interface, instead of just
traffic to 4.2.2.2
Tracing route to pfsense.org [69.64.6.13]
over a maximum of 30 hops:
11 ms1 ms1 ms 192.168.0.1
2 *** Request timed out.
338 ms38 ms39 ms 67.42.192.195
436 ms36 ms35 ms 67.42.192.125
535 ms36 ms35 ms 205.171.150.33
What's weirder is that the ISP on OPT1 is allowing the
traffic packets with my WAN interface IP to pass through
it. It doesn't appear to be nat'd to the OPT1 interface
IP either...
On Thu, Apr 05, 2007 at 11:38:27PM +0200, Holger Bauer wrote:
http://doc.pfsense.org/index.php/Multi-Wan/Load-Balancing
Holger
-Original Message-
From: Fuchs, Martin [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 05, 2007 11:13 PM
To: support@pfsense.com
Subject: AW: [pfSense Support] OK, I think this is simple...
I don't have thos config, but i could imagine it works with the gateway
option (select a gateway different than default) Perhaps it might be
necessary to define a pool or else fort hat...
Just try a bit :-)
Regards, Martin
-Urspr?ngliche Nachricht-
Von: Jaye Mathisen [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 5. April 2007 22:53
An: support@pfsense.com
Betreff: [pfSense Support] OK, I think this is simple...
-
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]
Re: [pfSense Support] IPSEC over an OPT interface Problems
I've just tested the most recent pfsense update available on http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ Here is the system's firmware information: 1.0.1-SNAPSHOT-03-27-2007 built on Mon Apr 2 19:21:19 EDT 2007 My results indicate that IPSEC over OPTx still does not work without explicitly opening UDP 500 and ESP on the interface in question to allow the interface's IP address to accept these two items. I believe that this may still be an older firmware, but I do not see a newer firmware available in the update format. At this time, I am also not in a position to test an .iso file. To do that, I will need to wait for the weekend when firewall usage is low. Vaughn On Fri, 30 Mar 2007 12:23:44 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: I'll check back later this evening or Monday day sometime. Thanks, Vaughn Scott Ullrich wrote: This is an old image. The snapshot server has been down for some time... Try again 2-3 hours from now or on Monday. Scott On 3/30/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I just tried implementing IPSEC over an OPT interface using the pfsense.iso file from March 29, 2007 at 7:19 p.m. Here are my results. IPSEC will not work over my OPT2 Interface without adding specific firewall rules to the OPT2 interface to allow UDP 500 and ESP to connect to that interface's IP address. Once I manually add the rules, the tunnels get created and work correctly over the OPT2 interface. Before I manually added the rules to the OPT2 interface, I noticed that there was no SAD listing to the tunnel being tested. Both ends of the tunnel were, however, listed on the SPD tab of the IPSEC tunnel diagnostic page. Once I added the needed firewall rules to the OPT2 interface, the VPN tunnel immediately set up and started working. At that time, the proper entries appeared in the SAD on the IPSEC diagnostic page. Also, I noticed during the loading of the pfsense firewall software while it was connecting services, etc. that an error message appeared that stated that there was an invalid argument foreach on line 7 of the /etc/inc/vslb.inc file. Don't quote me on the line number, but I'm pretty sure it was line 7. I'm not sure if this is related to my IPSEC issue, but I thought I'd comment in case it is relevant. Thanks, Vaughn Reid III Tunge2 wrote: If this is working it would be a great step a head :) -Oorspronkelijk bericht- Van: Vaughn L. Reid III [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 30 maart 2007 1:08 Aan: support@pfsense.com Onderwerp: Re: [pfSense Support] IPSEC over an OPT interface Problems Have the IPSEC changes been committed and built yet? I'm looking at the update files, and they all still say March 27 2007. I'm using this repository http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ Should I be looking somewhare else for the update with the IPSEC fix? Thanks, Vaughn On Thu, 29 Mar 2007 15:26:58 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: Thanks for your hard work. I appreciate it and I'm sure my customers do too. Vaughn Vaughn L. Reid III wrote: The ones ones that say Computer Support are from the test tunnel that I created to use OPT2. The interfaces on this machine are labeled like this: LAN = em0 WAN = em1 ATTDSL = em4 -- This is the OPT interface that I was using for the Computer Support VPN test wireless = em2 Vaughn Scott Ullrich wrote: Okay, so that I am on the same page as you. Those $wan rules should have read $optX ?? Scott On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick
Re: [pfSense Support] IPSEC over an OPT interface Problems
Here are the rules for the interface in question that seem to make the IPSEC tunnel work: Rules in the format listed below: Format: Protocol Source Port Destination Port Gateway Schedule 1. UDP * * Interface IP Address 500 * Blank 2. ESP * * Interface IP Address * * Blank Vaughn On Mon, 2 Apr 2007 20:11:10 -0400, Scott Ullrich [EMAIL PROTECTED] said: On 4/2/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I've just tested the most recent pfsense update available on http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ Please show the IPSEC rules that are relevant to the interface in question as you did prior. Thanks! - 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] IPSEC over an OPT interface Problems
Interesting, This version of the firmware doesn't even list the VPN tunnel that is configured for the OPT interface in the vpn section of /tmp/rules.debug. The tunnel definition is listed in the GUI, and it's working with the manual rules because I'm in the process of accessing remote resources now. In /tmp/rules.debug, however, it's like the vpn out the opt interface just doesn't exist. I checked the firewall rules section of /tmp/rules.debug, and the manual rules that I added are there. Also, the firmware version that I was using when I started this thread last week showed the VPN tunnel definition in /tmp/rules.debug, but it showed the wrong interface. Vaughn On Mon, 2 Apr 2007 20:32:47 -0400, Scott Ullrich [EMAIL PROTECTED] said: On 4/2/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Here are the rules for the interface in question that seem to make the IPSEC tunnel work: [snip] Look in /tmp/rules.debug and search for IPSEC. Do you see rules permitting traffic to the interface? Scott - 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] IPSEC over an OPT interface Problems
Just to be thorough, I added two more rules to the firewall's OPT interface to make sure all the IPSEC stuff gets through. I'm fuzzy on if the last two are needed, but just to be safe, I added them. Here are all the rule that I've added: Rules in the format listed below: Format: Protocol Source Port Destination Port Gateway Schedule 1. UDP * * Interface IP Address 500 * Blank 2. ESP * * Interface IP Address * * Blank 3. AH * * Interface IP Address * * Blank 4. GRE * * Interface IP Address * * Blank Vaughn On Mon, 02 Apr 2007 20:43:38 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: Interesting, This version of the firmware doesn't even list the VPN tunnel that is configured for the OPT interface in the vpn section of /tmp/rules.debug. The tunnel definition is listed in the GUI, and it's working with the manual rules because I'm in the process of accessing remote resources now. In /tmp/rules.debug, however, it's like the vpn out the opt interface just doesn't exist. I checked the firewall rules section of /tmp/rules.debug, and the manual rules that I added are there. Also, the firmware version that I was using when I started this thread last week showed the VPN tunnel definition in /tmp/rules.debug, but it showed the wrong interface. Vaughn On Mon, 2 Apr 2007 20:32:47 -0400, Scott Ullrich [EMAIL PROTECTED] said: On 4/2/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Here are the rules for the interface in question that seem to make the IPSEC tunnel work: [snip] Look in /tmp/rules.debug and search for IPSEC. Do you see rules permitting traffic to the interface? Scott - 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]
Re: [pfSense Support] IPSEC over an OPT interface Problems
I just tried implementing IPSEC over an OPT interface using the pfsense.iso file from March 29, 2007 at 7:19 p.m. Here are my results. IPSEC will not work over my OPT2 Interface without adding specific firewall rules to the OPT2 interface to allow UDP 500 and ESP to connect to that interface's IP address. Once I manually add the rules, the tunnels get created and work correctly over the OPT2 interface. Before I manually added the rules to the OPT2 interface, I noticed that there was no SAD listing to the tunnel being tested. Both ends of the tunnel were, however, listed on the SPD tab of the IPSEC tunnel diagnostic page. Once I added the needed firewall rules to the OPT2 interface, the VPN tunnel immediately set up and started working. At that time, the proper entries appeared in the SAD on the IPSEC diagnostic page. Also, I noticed during the loading of the pfsense firewall software while it was connecting services, etc. that an error message appeared that stated that there was an invalid argument foreach on line 7 of the /etc/inc/vslb.inc file. Don't quote me on the line number, but I'm pretty sure it was line 7. I'm not sure if this is related to my IPSEC issue, but I thought I'd comment in case it is relevant. Thanks, Vaughn Reid III Tunge2 wrote: If this is working it would be a great step a head :) -Oorspronkelijk bericht- Van: Vaughn L. Reid III [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 30 maart 2007 1:08 Aan: support@pfsense.com Onderwerp: Re: [pfSense Support] IPSEC over an OPT interface Problems Have the IPSEC changes been committed and built yet? I'm looking at the update files, and they all still say March 27 2007. I'm using this repository http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ Should I be looking somewhare else for the update with the IPSEC fix? Thanks, Vaughn On Thu, 29 Mar 2007 15:26:58 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: Thanks for your hard work. I appreciate it and I'm sure my customers do too. Vaughn Vaughn L. Reid III wrote: The ones ones that say Computer Support are from the test tunnel that I created to use OPT2. The interfaces on this machine are labeled like this: LAN = em0 WAN = em1 ATTDSL = em4 -- This is the OPT interface that I was using for the Computer Support VPN test wireless = em2 Vaughn Scott Ullrich wrote: Okay, so that I am on the same page as you. Those $wan rules should have read $optX ?? Scott On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC
Re: [pfSense Support] IPSEC over an OPT interface Problems
I'll check back later this evening or Monday day sometime. Thanks, Vaughn Scott Ullrich wrote: This is an old image. The snapshot server has been down for some time... Try again 2-3 hours from now or on Monday. Scott On 3/30/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I just tried implementing IPSEC over an OPT interface using the pfsense.iso file from March 29, 2007 at 7:19 p.m. Here are my results. IPSEC will not work over my OPT2 Interface without adding specific firewall rules to the OPT2 interface to allow UDP 500 and ESP to connect to that interface's IP address. Once I manually add the rules, the tunnels get created and work correctly over the OPT2 interface. Before I manually added the rules to the OPT2 interface, I noticed that there was no SAD listing to the tunnel being tested. Both ends of the tunnel were, however, listed on the SPD tab of the IPSEC tunnel diagnostic page. Once I added the needed firewall rules to the OPT2 interface, the VPN tunnel immediately set up and started working. At that time, the proper entries appeared in the SAD on the IPSEC diagnostic page. Also, I noticed during the loading of the pfsense firewall software while it was connecting services, etc. that an error message appeared that stated that there was an invalid argument foreach on line 7 of the /etc/inc/vslb.inc file. Don't quote me on the line number, but I'm pretty sure it was line 7. I'm not sure if this is related to my IPSEC issue, but I thought I'd comment in case it is relevant. Thanks, Vaughn Reid III Tunge2 wrote: If this is working it would be a great step a head :) -Oorspronkelijk bericht- Van: Vaughn L. Reid III [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 30 maart 2007 1:08 Aan: support@pfsense.com Onderwerp: Re: [pfSense Support] IPSEC over an OPT interface Problems Have the IPSEC changes been committed and built yet? I'm looking at the update files, and they all still say March 27 2007. I'm using this repository http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ Should I be looking somewhare else for the update with the IPSEC fix? Thanks, Vaughn On Thu, 29 Mar 2007 15:26:58 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: Thanks for your hard work. I appreciate it and I'm sure my customers do too. Vaughn Vaughn L. Reid III wrote: The ones ones that say Computer Support are from the test tunnel that I created to use OPT2. The interfaces on this machine are labeled like this: LAN = em0 WAN = em1 ATTDSL = em4 -- This is the OPT interface that I was using for the Computer Support VPN test wireless = em2 Vaughn Scott Ullrich wrote: Okay, so that I am on the same page as you. Those $wan rules should have read $optX ?? Scott On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label
[pfSense Support] Connectivity Issue with second OPT interface
I am running the 3-27 snapshot of pfsense. I've been testing out adding a 2nd OPT interface that goes to remote sites over a wireless link. A dedicated access point is doing all the wireless stuff, so that is not a responsibility of the pfsense box. Here's my problem though. I can ping remote hosts from the pfsense box and can ping the remote hosts from the LAN interface. Remote hosts show up in my arp table on the pfsense box and remote hosts can see the pfsense box in their arp tables. I have a firewall rule configured to all all traffic going into and coming out of the interface on the pfsense box (Once I get things working, I'll lock this down some). Firewall Rule: Proto * Source * Destination * Port * Gateway * The firewall log shows that the pfsense box is accepting inbound requests, but nothing happens. The remote hosts can't ping the pfsense machine, connect to it in any way, or access resources that lie behind it. I do not have a NAT rule set for this interface, and I'm using Advanced NAT. I don't want to perform NAT on this interface, just routing. The IP of the OPT interface on the pfsense box is 172.16.125.1/24 with no gateway defined for the interface. All of the remote hosts are in the 172.16.125.0/24 subnet and they have the pfsense box set up as their default gateway. The diagnostic = routes page shows the correct interface as for the route to the 172.16.125.0/24 network and also shows a route to each host. Am I missing something that I need to have configured that I don't? My other OPT interface to a dsl connection is working correctly. Thanks, Vaughn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] IPSEC over an OPT interface Problems
I'm using the 3-27 snapshot on the pfsense box. I've searched both the forum and the mailing list archives, and I can't seem to find an updated listing of how to get IPSEC to work over an OPT interface as well as over WAN at the Same time. Here's what I want to do: I have several remote sites that use one of two companies for their Internet access. Our main office also has Internet access through these two ISP's. I want to configure the tunnels that have Internet access through ISP A to use our ISP A connection, which is WAN, and those that have ISP B, which is our OPT1, to use ISP B's interface on the pfsense box for IPSEC vpn's. I can get all of the VPN connections to work properly if they all use the WAN interface, but this adds about 5 hops and 50 milli-seconds to the round trip for those remotes that use ISP B. Here's what I tried without success: On the pfsense box, I changed the existing working configurations for the desired VPN tunnels to use the OPT interface. I then saved my changed settings and clicked the Apply button. At the desired remote sites, I changed the remote Gateway IP on their (previously working when using WAN) existing VPN tunnel configurations to use the OPT interface's IP address. After doing this, I rebooted both the pfsense box and the remote router. Also, the IPSEC interface has the default rule to allow all connections and all traffic. Both the pfsense machine and the remote sites have static IP's for their Internet connections. The remote sites are using linksys RV series firewalls. The dsl router at the main site for the OPT interface is a netopia 3500 and it is set to bridge mode so that the OPT interface has a real public IP. Any help will be appreciated. Thanks, Vaughn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Connectivity Issue with second OPT interface
Thanks for the link. I've been looking for a definitive how-to for load balancing. It appears to have more information than some of the other documentation. I'm not, however, actually using the OPT2 as a Wan link. I just want to use it to act, basically, like a separate subnet on the network. All the nodes that connect to that interface are on the same subnet as the interface itself, they can all see each other in arp, and I can ping out from both the pfsense box and the LAN interface and get a reply from the other nodes on OPT2. The problem is that they can't see or ping or connect to either the pfsense machine or to anything on the lan interface. I added a rule to the firewall rules page for this interface to allow all traffic into and out of the interface. And the firewall logs show that connection attempts are accepted. But, none of the remote nodes get responses to their traffic. Vaughn Scott Ullrich wrote: We have docs concerning multi-wan. Please ensure that you have double checked your settings. http://doc.pfsense.org/index.php/Multi-Wan/Load-Balancing I run multi-wan at work and it absolutely works. Scott On 3/29/07, Robert Goley [EMAIL PROTECTED] wrote: It seems we are both having the same basic issue. I am assuming that you are able to connect out via the same OPT2 interface you are trying to connect in thru. I wish I had more answer for you than I am having this trouble too. No one has responded to my emails. If I find the source of my problem, I will let you know. Robert On Thursday 29 March 2007 07:13, Vaughn L. Reid III wrote: I am running the 3-27 snapshot of pfsense. I've been testing out adding a 2nd OPT interface that goes to remote sites over a wireless link. A dedicated access point is doing all the wireless stuff, so that is not a responsibility of the pfsense box. Here's my problem though. I can ping remote hosts from the pfsense box and can ping the remote hosts from the LAN interface. Remote hosts show up in my arp table on the pfsense box and remote hosts can see the pfsense box in their arp tables. I have a firewall rule configured to all all traffic going into and coming out of the interface on the pfsense box (Once I get things working, I'll lock this down some). Firewall Rule: Proto * Source * Destination * Port * Gateway * The firewall log shows that the pfsense box is accepting inbound requests, but nothing happens. The remote hosts can't ping the pfsense machine, connect to it in any way, or access resources that lie behind it. I do not have a NAT rule set for this interface, and I'm using Advanced NAT. I don't want to perform NAT on this interface, just routing. The IP of the OPT interface on the pfsense box is 172.16.125.1/24 with no gateway defined for the interface. All of the remote hosts are in the 172.16.125.0/24 subnet and they have the pfsense box set up as their default gateway. The diagnostic = routes page shows the correct interface as for the route to the 172.16.125.0/24 network and also shows a route to each host. Am I missing something that I need to have configured that I don't? My other OPT interface to a dsl connection is working correctly. Thanks, Vaughn - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC over an OPT interface Problems
I've set up a test tunnel between my office and my customer site. The VPN tunnel will work correctly when the pfsense interface is the WAN interface. When I change the interface to the OPT interface, It doesn't seem to work. Here are some log entries. racoon: ERROR: phase1 negotiation failed due to time up. 8c35cc8f9a4378c0: Mar 29 13:36:29 racoon: INFO: delete phase 2 handler. Mar 29 13:36:29 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 70.237.44.110[500]-75.44.169.169[500] Mar 29 13:35:58 racoon: INFO: begin Aggressive mode. Mar 29 13:35:58 racoon: INFO: initiate new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 13:35:58 racoon: INFO: IPsec-SA request for 70.237.44.110 queued due to no phase1 found. Mar 29 13:32:04 racoon: ERROR: phase1 negotiation failed due to time up. 022718bb87e94fd7: Mar 29 13:31:35 racoon: INFO: delete phase 2 handler. Mar 29 13:31:35 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 70.237.44.110[500]-75.44.169.169[500] Mar 29 13:31:04 racoon: INFO: begin Aggressive mode. Mar 29 13:31:04 racoon: INFO: initiate new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 13:31:04 racoon: INFO: IPsec-SA request for 70.237.44.110 queued due to no phase1 found. This set of responses just seem to repeat themselves over and over again. If I set the remote node to use the pfsense's WAN ip and change the tunnel definition on the pfsense box to use the WAN interface, then everything immediately works after hitting the save and apply buttons. Thanks, Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I'm using the 3-27 snapshot on the pfsense box. I've searched both the forum and the mailing list archives, and I can't seem to find an updated listing of how to get IPSEC to work over an OPT interface as well as over WAN at the Same time. Here's what I want to do: I have several remote sites that use one of two companies for their Internet access. Our main office also has Internet access through these two ISP's. I want to configure the tunnels that have Internet access through ISP A to use our ISP A connection, which is WAN, and those that have ISP B, which is our OPT1, to use ISP B's interface on the pfsense box for IPSEC vpn's. I can get all of the VPN connections to work properly if they all use the WAN interface, but this adds about 5 hops and 50 milli-seconds to the round trip for those remotes that use ISP B. Here's what I tried without success: On the pfsense box, I changed the existing working configurations for the desired VPN tunnels to use the OPT interface. I then saved my changed settings and clicked the Apply button. At the desired remote sites, I changed the remote Gateway IP on their (previously working when using WAN) existing VPN tunnel configurations to use the OPT interface's IP address. After doing this, I rebooted both the pfsense box and the remote router. Also, the IPSEC interface has the default rule to allow all connections and all traffic. Both the pfsense machine and the remote sites have static IP's for their Internet connections. The remote sites are using linksys RV series firewalls. The dsl router at the main site for the OPT interface is a netopia 3500 and it is set to bridge mode so that the OPT interface has a real public IP. Please post the IPSEC logs from the pfSense box. Scott - 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] IPSEC over an OPT interface Problems
I changed the My Identifier on the tunnel definition to IP Address and then specified 75.44.169.169. I clicked save and apply. When I did this, the tunnel still did not work. In addition, all mention of the tunnel stopped in the IPSEC logs. I have confirmed that I can ping the 75.44.169.169 IP from the remote gateway and that it is the OPT2 IP for the pfsense box. I also confirmed that I can ssh into the pfsense machine using the above IP address. Are there any special firewall or NAT rules that I need to set up the OPT2 interface to get it to accept an IPSEC tunnel? I noticed that, for WAN at least, that those rules are automatically created and are not visible on the rules page. Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I've set up a test tunnel between my office and my customer site. The VPN tunnel will work correctly when the pfsense interface is the WAN interface. When I change the interface to the OPT interface, It doesn't seem to work. Here are some log entries. racoon: ERROR: phase1 negotiation failed due to time up. 8c35cc8f9a4378c0: Mar 29 13:36:29 racoon: INFO: delete phase 2 handler. Mar 29 13:36:29 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 70.237.44.110[500]-75.44.169.169[500] Mar 29 13:35:58 racoon: INFO: begin Aggressive mode. Mar 29 13:35:58 racoon: INFO: initiate new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 13:35:58 racoon: INFO: IPsec-SA request for 70.237.44.110 queued due to no phase1 found. Mar 29 13:32:04 racoon: ERROR: phase1 negotiation failed due to time up. 022718bb87e94fd7: Mar 29 13:31:35 racoon: INFO: delete phase 2 handler. Mar 29 13:31:35 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 70.237.44.110[500]-75.44.169.169[500] Mar 29 13:31:04 racoon: INFO: begin Aggressive mode. Mar 29 13:31:04 racoon: INFO: initiate new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 13:31:04 racoon: INFO: IPsec-SA request for 70.237.44.110 queued due to no phase1 found. This set of responses just seem to repeat themselves over and over again. If I set the remote node to use the pfsense's WAN ip and change the tunnel definition on the pfsense box to use the WAN interface, then everything immediately works after hitting the save and apply buttons. Please verify that the IP addresses match up in the report below. You can also change My Identifier to IP Address and manually type in the OPT interface IP. Does that fix it? If so please show the log files differences. Scott - 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] IPSEC over an OPT interface Problems
I have only the default allow everything rule on the IPSEC tab. I manually added rules to the firewall to allow UDP 500 to the OPT2 interface and to allow ESP to the OPT2 interface, and now I'm getting different IPSEC log results (I changed the My Identifier back to interface address). Here are the new log entries: Mar 29 14:20:20 racoon: ERROR: pfkey DELETE received: ESP 75.44.169.169[0]-70.237.44.110[0] spi=3627103776(0xd8313620) Mar 29 14:19:21 racoon: INFO: IPsec-SA established: ESP/Tunnel 75.44.169.169[0]-70.237.44.110[0] spi=3097439008(0xb89f2b20) Mar 29 14:19:21 racoon: INFO: IPsec-SA established: ESP/Tunnel 70.237.44.110[0]-75.44.169.169[0] spi=129752861(0x7bbdf1d) Mar 29 14:19:21 racoon: INFO: respond new phase 2 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 14:19:21 racoon: INFO: ISAKMP-SA established 75.44.169.169[500]-70.237.44.110[500] spi:72fba3fecd3739c6:f7fb0fc1959fdf21 Mar 29 14:19:20 racoon: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address. Mar 29 14:19:20 racoon: INFO: begin Aggressive mode. Mar 29 14:19:20 racoon: INFO: respond new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 14:17:43 racoon: ERROR: pfkey DELETE received: ESP 75.44.169.169[0]-70.237.44.110[0] spi=754453952(0x2cf80dc0) Mar 29 14:17:43 racoon: ERROR: pfkey DELETE received: ESP 75.44.169.169[0]-70.237.44.110[0] spi=2451182496(0x921a13a0) Mar 29 14:17:03 racoon: INFO: IPsec-SA established: ESP/Tunnel 75.44.169.169[0]-70.237.44.110[0] spi=3627103776(0xd8313620) Mar 29 14:17:03 racoon: INFO: IPsec-SA established: ESP/Tunnel 70.237.44.110[0]-75.44.169.169[0] spi=101957205(0x613be55) Mar 29 14:17:03 racoon: INFO: respond new phase 2 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 14:17:03 racoon: INFO: ISAKMP-SA established 75.44.169.169[500]-70.237.44.110[500] spi:8203621148841b41:6ad562eb830dd2d5 Mar 29 14:17:02 racoon: NOTIFY: couldn't find the proper pskey, try to get one by the peer's address. Mar 29 14:17:02 racoon: INFO: begin Aggressive mode. Mar 29 14:17:02 racoon: INFO: respond new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I changed the My Identifier on the tunnel definition to IP Address and then specified 75.44.169.169. I clicked save and apply. When I did this, the tunnel still did not work. In addition, all mention of the tunnel stopped in the IPSEC logs. I have confirmed that I can ping the 75.44.169.169 IP from the remote gateway and that it is the OPT2 IP for the pfsense box. I also confirmed that I can ssh into the pfsense machine using the above IP address. Are there any special firewall or NAT rules that I need to set up the OPT2 interface to get it to accept an IPSEC tunnel? I noticed that, for WAN at least, that those rules are automatically created and are not visible on the rules page. Nothing else is required except for a pass rule on the IPSEC tab on recent snapshots. I am running a tunnel on a opt1 interface and it works fine here. Scott - 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] IPSEC over an OPT interface Problems
I changed the My Identifier on the tunnel definition to IP Address and then specified 75.44.169.169. I clicked save and apply. When I did this, the tunnel still did not work. In addition, all mention of the tunnel stopped in the IPSEC logs. I have confirmed that I can ping the 75.44.169.169 IP from the remote gateway and that it is the OPT2 IP for the pfsense box. I also confirmed that I can ssh into the pfsense machine using the above IP address. Are there any special firewall or NAT rules that I need to set up the OPT2 interface to get it to accept an IPSEC tunnel? I noticed that, for WAN at least, that those rules are automatically created and are not visible on the rules page. Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I've set up a test tunnel between my office and my customer site. The VPN tunnel will work correctly when the pfsense interface is the WAN interface. When I change the interface to the OPT interface, It doesn't seem to work. Here are some log entries. racoon: ERROR: phase1 negotiation failed due to time up. 8c35cc8f9a4378c0: Mar 29 13:36:29 racoon: INFO: delete phase 2 handler. Mar 29 13:36:29 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 70.237.44.110[500]-75.44.169.169[500] Mar 29 13:35:58 racoon: INFO: begin Aggressive mode. Mar 29 13:35:58 racoon: INFO: initiate new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 13:35:58 racoon: INFO: IPsec-SA request for 70.237.44.110 queued due to no phase1 found. Mar 29 13:32:04 racoon: ERROR: phase1 negotiation failed due to time up. 022718bb87e94fd7: Mar 29 13:31:35 racoon: INFO: delete phase 2 handler. Mar 29 13:31:35 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 70.237.44.110[500]-75.44.169.169[500] Mar 29 13:31:04 racoon: INFO: begin Aggressive mode. Mar 29 13:31:04 racoon: INFO: initiate new phase 1 negotiation: 75.44.169.169[500]=70.237.44.110[500] Mar 29 13:31:04 racoon: INFO: IPsec-SA request for 70.237.44.110 queued due to no phase1 found. This set of responses just seem to repeat themselves over and over again. If I set the remote node to use the pfsense's WAN ip and change the tunnel definition on the pfsense box to use the WAN interface, then everything immediately works after hitting the save and apply buttons. Please verify that the IP addresses match up in the report below. You can also change My Identifier to IP Address and manually type in the OPT interface IP. Does that fix it? If so please show the log files differences. Scott - 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] IPSEC over an OPT interface Problems
After I let the connection set for a couple minutes after manually adding the UDP 500 and ESP rules, the tunnel started working. Yeah!!! Assuming that I will need to manually add the rules to the OPT2 interface, are there any additional rules that need to be added for IPSEC? Also, here are the log entries now that the tunnel is up. Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 192.168.10.1[500] used as isakmp port (fd=22) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%em0[500] used as isakmp port (fd=21) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 209.218.218.138[500] used as isakmp port (fd=20) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b8a6%em1[500] used as isakmp port (fd=19) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 75.44.169.169[500] used as isakmp port (fd=18) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b88d%em4[500] used as isakmp port (fd=17) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=16) Mar 29 14:24:41 racoon: INFO: ::1[500] used as isakmp port (fd=15) Mar 29 14:24:41 racoon: INFO: fe80::1%lo0[500] used as isakmp port (fd=14) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%ng1[500] used as isakmp port (fd=13) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 192.168.10.1[500] used as isakmp port (fd=22) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%em0[500] used as isakmp port (fd=21) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 209.218.218.138[500] used as isakmp port (fd=20) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b8a6%em1[500] used as isakmp port (fd=19) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 75.44.169.169[500] used as isakmp port (fd=18) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b88d%em4[500] used as isakmp port (fd=17) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=16) Mar 29 14:24:41 racoon: INFO: ::1[500] used as isakmp port (fd=15) Mar 29 14:24:41 racoon: INFO: fe80::1%lo0[500] used as isakmp port (fd=14) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%ng1[500] used as isakmp port (fd=13) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 192.168.10.1[500] used as isakmp port (fd=22) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%em0[500] used as isakmp port (fd=21) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 209.218.218.138[500] used as isakmp port (fd=20) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b8a6%em1[500] used as isakmp port (fd=19) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 75.44.169.169[500] used as isakmp port (fd=18) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b88d%em4[500] used as isakmp port (fd=17) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=16) Mar 29 14:24:41 racoon: INFO: ::1[500] used as isakmp port (fd=15) Mar 29 14:24:41 racoon: INFO: fe80::1%lo0[500] used as isakmp port (fd=14) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%ng1[500] used as isakmp port (fd=13) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 192.168.10.1[500] used as isakmp port (fd=22) Mar 29 14:24:41 racoon: INFO: fe80::2e0:81ff:fe74:bb24%em0[500] used as isakmp port (fd=21) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 209.218.218.138[500] used as isakmp port (fd=20) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b8a6%em1[500] used as isakmp port (fd=19) Mar 29 14:24:41 racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument Mar 29 14:24:41 racoon: INFO: 75.44.169.169[500] used as isakmp port (fd=18) Mar 29 14:24:41 racoon: INFO: fe80::204:23ff:fede:b88d%em4[500] used as isakmp port (fd=17) Thanks, Vaughn Reid III Vaughn L. Reid III wrote: I have only the default allow everything rule on the IPSEC tab. I manually added rules to the firewall to allow UDP 500 to the OPT2
Re: [pfSense Support] IPSEC over an OPT interface Problems
Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC: Street Department - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.129 keep state label IPSEC: Street Department - outbound esp proto pass in quick on $wan proto esp from 65.119.178.129 to 209.218.218.138 keep state label IPSEC: Street Department - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.154 port = 500 keep state label IPSEC: Fire Station 2 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.154 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 2 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.154 keep state label IPSEC: Fire Station 2 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.154 to 209.218.218.138 keep state label IPSEC: Fire Station 2 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.227.28.14 port = 500 keep state label IPSEC: EMS Building - outbound isakmp pass in quick on $wan proto udp from 70.227.28.14 to 209.218.218.138 port = 500 keep state label IPSEC: EMS Building - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.227.28.14 keep state label IPSEC: EMS Building - outbound esp proto pass in quick on $wan proto esp from 70.227.28.14 to 209.218.218.138 keep state label IPSEC: EMS Building - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.237.44.110 port = 500 keep state label IPSEC: Computer Support - outbound isakmp pass in quick on $wan proto udp from 70.237.44.110 to 209.218.218.138 port = 500 keep state label IPSEC: Computer Support - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.237.44.110 keep state label IPSEC: Computer Support - outbound esp proto pass in quick on $wan proto esp from 70.237.44.110 to 209.218.218.138 keep state label IPSEC: Computer Support - inbound esp proto pass in quick on em0 inet proto tcp from any to $loopback port 8021 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em0 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em1 inet proto tcp from port 20 to (em1) port 49000 user proxy flags S/SA keep state label FTP PROXY: PASV mode data connection # enable ftp-proxy pass in quick on em4 inet proto tcp from any to $loopback port 8022 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em4 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I didn't get the request, but I'll be happy check to see if rules are being added. Should I remove
Re: [pfSense Support] IPSEC over an OPT interface Problems
Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC: Street Department - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.129 keep state label IPSEC: Street Department - outbound esp proto pass in quick on $wan proto esp from 65.119.178.129 to 209.218.218.138 keep state label IPSEC: Street Department - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.154 port = 500 keep state label IPSEC: Fire Station 2 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.154 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 2 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.154 keep state label IPSEC: Fire Station 2 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.154 to 209.218.218.138 keep state label IPSEC: Fire Station 2 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.227.28.14 port = 500 keep state label IPSEC: EMS Building - outbound isakmp pass in quick on $wan proto udp from 70.227.28.14 to 209.218.218.138 port = 500 keep state label IPSEC: EMS Building - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.227.28.14 keep state label IPSEC: EMS Building - outbound esp proto pass in quick on $wan proto esp from 70.227.28.14 to 209.218.218.138 keep state label IPSEC: EMS Building - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.237.44.110 port = 500 keep state label IPSEC: Computer Support - outbound isakmp pass in quick on $wan proto udp from 70.237.44.110 to 209.218.218.138 port = 500 keep state label IPSEC: Computer Support - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.237.44.110 keep state label IPSEC: Computer Support - outbound esp proto pass in quick on $wan proto esp from 70.237.44.110 to 209.218.218.138 keep state label IPSEC: Computer Support - inbound esp proto pass in quick on em0 inet proto tcp from any to $loopback port 8021 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em0 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em1 inet proto tcp from port 20 to (em1) port 49000 user proxy flags S/SA keep state label FTP PROXY: PASV mode data connection # enable ftp-proxy pass in quick on em4 inet proto tcp from any to $loopback port 8022 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em4 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I didn't get the request, but I'll be happy check to see if rules are being added. Should I remove
Re: [pfSense Support] IPSEC over an OPT interface Problems
Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC: Street Department - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.129 keep state label IPSEC: Street Department - outbound esp proto pass in quick on $wan proto esp from 65.119.178.129 to 209.218.218.138 keep state label IPSEC: Street Department - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.154 port = 500 keep state label IPSEC: Fire Station 2 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.154 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 2 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.154 keep state label IPSEC: Fire Station 2 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.154 to 209.218.218.138 keep state label IPSEC: Fire Station 2 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.227.28.14 port = 500 keep state label IPSEC: EMS Building - outbound isakmp pass in quick on $wan proto udp from 70.227.28.14 to 209.218.218.138 port = 500 keep state label IPSEC: EMS Building - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.227.28.14 keep state label IPSEC: EMS Building - outbound esp proto pass in quick on $wan proto esp from 70.227.28.14 to 209.218.218.138 keep state label IPSEC: EMS Building - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.237.44.110 port = 500 keep state label IPSEC: Computer Support - outbound isakmp pass in quick on $wan proto udp from 70.237.44.110 to 209.218.218.138 port = 500 keep state label IPSEC: Computer Support - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.237.44.110 keep state label IPSEC: Computer Support - outbound esp proto pass in quick on $wan proto esp from 70.237.44.110 to 209.218.218.138 keep state label IPSEC: Computer Support - inbound esp proto pass in quick on em0 inet proto tcp from any to $loopback port 8021 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em0 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em1 inet proto tcp from port 20 to (em1) port 49000 user proxy flags S/SA keep state label FTP PROXY: PASV mode data connection # enable ftp-proxy pass in quick on em4 inet proto tcp from any to $loopback port 8022 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em4 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost Vaughn Scott Ullrich wrote: On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I didn't get the request, but I'll
Re: [pfSense Support] IPSEC over an OPT interface Problems
The ones ones that say Computer Support are from the test tunnel that I created to use OPT2. The interfaces on this machine are labeled like this: LAN = em0 WAN = em1 ATTDSL = em4 -- This is the OPT interface that I was using for the Computer Support VPN test wireless = em2 Vaughn Scott Ullrich wrote: Okay, so that I am on the same page as you. Those $wan rules should have read $optX ?? Scott On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC: Street Department - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.129 keep state label IPSEC: Street Department - outbound esp proto pass in quick on $wan proto esp from 65.119.178.129 to 209.218.218.138 keep state label IPSEC: Street Department - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.154 port = 500 keep state label IPSEC: Fire Station 2 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.154 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 2 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.154 keep state label IPSEC: Fire Station 2 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.154 to 209.218.218.138 keep state label IPSEC: Fire Station 2 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.227.28.14 port = 500 keep state label IPSEC: EMS Building - outbound isakmp pass in quick on $wan proto udp from 70.227.28.14 to 209.218.218.138 port = 500 keep state label IPSEC: EMS Building - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.227.28.14 keep state label IPSEC: EMS Building - outbound esp proto pass in quick on $wan proto esp from 70.227.28.14 to 209.218.218.138 keep state label IPSEC: EMS Building - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.237.44.110 port = 500 keep state label IPSEC: Computer Support - outbound isakmp pass in quick on $wan proto udp from 70.237.44.110 to 209.218.218.138 port = 500 keep state label IPSEC: Computer Support - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.237.44.110 keep state label IPSEC: Computer Support - outbound esp proto pass in quick on $wan proto esp from 70.237.44.110 to 209.218.218.138 keep state label IPSEC: Computer Support - inbound esp proto pass in quick on em0 inet proto tcp from any to $loopback port 8021 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em0 inet proto tcp from any to $loopback port 21 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em1 inet proto tcp
Re: [pfSense Support] IPSEC over an OPT interface Problems
Thanks for your hard work. I appreciate it and I'm sure my customers do too. Vaughn Vaughn L. Reid III wrote: The ones ones that say Computer Support are from the test tunnel that I created to use OPT2. The interfaces on this machine are labeled like this: LAN = em0 WAN = em1 ATTDSL = em4 -- This is the OPT interface that I was using for the Computer Support VPN test wireless = em2 Vaughn Scott Ullrich wrote: Okay, so that I am on the same page as you. Those $wan rules should have read $optX ?? Scott On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC: Street Department - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.129 keep state label IPSEC: Street Department - outbound esp proto pass in quick on $wan proto esp from 65.119.178.129 to 209.218.218.138 keep state label IPSEC: Street Department - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.154 port = 500 keep state label IPSEC: Fire Station 2 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.154 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 2 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.154 keep state label IPSEC: Fire Station 2 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.154 to 209.218.218.138 keep state label IPSEC: Fire Station 2 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.227.28.14 port = 500 keep state label IPSEC: EMS Building - outbound isakmp pass in quick on $wan proto udp from 70.227.28.14 to 209.218.218.138 port = 500 keep state label IPSEC: EMS Building - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.227.28.14 keep state label IPSEC: EMS Building - outbound esp proto pass in quick on $wan proto esp from 70.227.28.14 to 209.218.218.138 keep state label IPSEC: EMS Building - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.237.44.110 port = 500 keep state label IPSEC: Computer Support - outbound isakmp pass in quick on $wan proto udp from 70.237.44.110 to 209.218.218.138 port = 500 keep state label IPSEC: Computer Support - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.237.44.110 keep state label IPSEC: Computer Support - outbound esp proto pass in quick on $wan proto esp from 70.237.44.110 to 209.218.218.138 keep state label IPSEC: Computer Support - inbound esp proto pass in quick on em0 inet proto tcp from any to $loopback port 8021 keep state label FTP PROXY: Allow traffic to localhost pass in quick on em0
Re: [pfSense Support] IPSEC over an OPT interface Problems
Have the IPSEC changes been committed and built yet? I'm looking at the update files, and they all still say March 27 2007. I'm using this repository http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ Should I be looking somewhare else for the update with the IPSEC fix? Thanks, Vaughn On Thu, 29 Mar 2007 15:26:58 -0400, Vaughn L. Reid III [EMAIL PROTECTED] said: Thanks for your hard work. I appreciate it and I'm sure my customers do too. Vaughn Vaughn L. Reid III wrote: The ones ones that say Computer Support are from the test tunnel that I created to use OPT2. The interfaces on this machine are labeled like this: LAN = em0 WAN = em1 ATTDSL = em4 -- This is the OPT interface that I was using for the Computer Support VPN test wireless = em2 Vaughn Scott Ullrich wrote: Okay, so that I am on the same page as you. Those $wan rules should have read $optX ?? Scott On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Oops! Sorry for the double post. Vaughn L. Reid III wrote: Here is the relevant text of my rules.debug file. It looks like the interface on the connection computer support has the same interface as the rest of the tunnels. This is the test connection that should be using OPT3. # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on $lan proto icmp keep state label let out anything from firewall host itself pass out quick on $wan proto icmp keep state label let out anything from firewall host itself pass out quick on em1 all keep state label let out anything from firewall host itself # pass traffic from firewall - out anchor firewallout pass out quick on em1 all keep state label let out anything from firewall host itself pass out quick on em0 all keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself pass out quick on em2 all keep state label let out anything from firewall host itself pass out quick on $pptp all keep state label let out anything from firewall host itself pptp pass out quick on $enc0 keep state label IPSEC internal host to host # let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on em4 proto icmp keep state label let out anything from firewall host itself pass out quick on em4 all keep state label let out anything from firewall host itself # VPN Rules pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.137 port = 500 keep state label IPSEC: Fire Station 3 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.137 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 3 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.137 keep state label IPSEC: Fire Station 3 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.137 to 209.218.218.138 keep state label IPSEC: Fire Station 3 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.129 port = 500 keep state label IPSEC: Street Department - outbound isakmp pass in quick on $wan proto udp from 65.119.178.129 to 209.218.218.138 port = 500 keep state label IPSEC: Street Department - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.129 keep state label IPSEC: Street Department - outbound esp proto pass in quick on $wan proto esp from 65.119.178.129 to 209.218.218.138 keep state label IPSEC: Street Department - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 65.119.178.154 port = 500 keep state label IPSEC: Fire Station 2 - outbound isakmp pass in quick on $wan proto udp from 65.119.178.154 to 209.218.218.138 port = 500 keep state label IPSEC: Fire Station 2 - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 65.119.178.154 keep state label IPSEC: Fire Station 2 - outbound esp proto pass in quick on $wan proto esp from 65.119.178.154 to 209.218.218.138 keep state label IPSEC: Fire Station 2 - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.227.28.14 port = 500 keep state label IPSEC: EMS Building - outbound isakmp pass in quick on $wan proto udp from 70.227.28.14 to 209.218.218.138 port = 500 keep state label IPSEC: EMS Building - inbound isakmp pass out quick on $wan proto esp from 209.218.218.138 to 70.227.28.14 keep state label IPSEC: EMS Building - outbound esp proto pass in quick on $wan proto esp from 70.227.28.14 to 209.218.218.138 keep state label IPSEC: EMS Building - inbound esp proto pass out quick on $wan proto udp from 209.218.218.138 to 70.237.44.110 port = 500 keep state label IPSEC: Computer Support
[pfSense Support] IPSec Keep Alive Question
I have a question about the IPSec keep-alive feature in pfsense. What is the preferred IP address to ping with this feature, the public IP of the remote tunnel end-point, or a host that is not the remote router on the private network side of the remote end-point, or the private IP address of the remote router? Thanks, Vaughn Reid III - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] IPSec Keep Alive Question
Thanks for the information. I appreciate it. Vaughn Reid III On Mon, 26 Mar 2007 16:32:01 +0200, Holger Bauer [EMAIL PROTECTED] said: Any IP in the remote subnet range (remote internal IP that is inside the remote subnet tunnel definition). It doesn't even have to answer or exist. It's just to bring up the tunnel or keep it alive as there is traffic for the remote subnet. Holger -Original Message- From: Vaughn L. Reid III [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 1:53 PM To: support@pfsense.com Subject: [pfSense Support] IPSec Keep Alive Question I have a question about the IPSec keep-alive feature in pfsense. What is the preferred IP address to ping with this feature, the public IP of the remote tunnel end-point, or a host that is not the remote router on the private network side of the remote end-point, or the private IP address of the remote router? Thanks, Vaughn Reid III - 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] -- Vaughn L. Reid III [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Firewall Rule Help?
Oops! I found my firewall configuration problem. I managed to put allow * from 192.168.0.0/24 to * on the LAN interface of the firewall rules page. Once I changed it to allow * from 192.168.0.0/16 to * on the LAN interface, everything worked properly. That will teach me to do firewall configs after midnight. :-) Vaughn Vaughn L. Reid III wrote: I'll post the config file a little later today, when I get to my test box. In the mean time, I want to make it clear that subnet 2 is not directly connected to the pfsense box. Currently, the pfsense box has 4 interfaces: a Lan interface which is connected to subnet 1, a Wan interface, and 2 Opt interfaces. Opt 1 is called ATTDSL. This interface is the point of internet contact for a proxy server that lives on subnet 1 and was configured for this usage via a firewall rule as described in the policy routing tutorial on the pfsense website. The second Opt interface is called Wireless and will be used to test external VPN connections between offices via 802.11 access points. Subnet 2 is not directly physically connected to the pfsense box. An openSuse router sits between subnet 1 and subnet 2 and handles routing between these two subnets. A review of the symptoms of the problem that I'm having is that when I replace the pfsense with a linksys RV series router or Hotbrick router, both subnet 1 and subnet 2 are able to access the internet and to ping the router. When the pfsense box is in place, even with explicit rules allowing all traffic to all locations from the entire 192.168.0.0/16 network on the LAN interface, the pfsense box explicitly denies and logs all traffic trying to pass to it or through it from subnet 2. Vaughn sai wrote: On 3/18/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I have a pfsense firewall in a test network like the one below. Internet provider 1 | | provider 2 Pfsense Firewall -- LAN IP 192.168.10.1/24 | Subnet 1 -- 192.168.10.x/24 | Internal Router -- Subnet 1 IP 192.168.10.14 -- Subnet 2 IP 192.168.12.1 | Subnet 2 192.168.12.x/24 I am having trouble getting the clients on Subnet 2 to get access to either the Internet or to the interface of the pfsense box. I have the following rules entered into the firewall and NAT: Firewall: LAN Allow * from 192.168.0.0/16 to * NAT: Do Outbound NAT on 192.168.0.0/16 Here are the symptoms of the problem that I'm having. When I try to ping or connect to the pfsense box from subnet 1, I can ping and connect to it without any problems. When I try to ping or connect to it from subnet 2, the connection is refused. In addition, I can connect to Internet resources normally from subnet 1, but not from subnet 2. I thought that maybe the internal router was the problem, so I replaced the pfsense box with an el-cheapo router and everything worked correctly from both subnets without any changes to the internal router. I have also tried specifying allow rules for each subnet in the pfsense firewall rules page, but that seemed to have no effect. I am using the March 18th, 2007 daily build of the pfsense stable. I also noticed that the firewall log on the pfsense box is logging that it is dropping everything that is coming to it from subnet 2. If anyone can help me come up with a solution, I'd appreciate it. Thanks, Vaughn Firewall Rules add a rule for the subnet2 interface that allows the traffic. post the config for the interface and also the firewall rules for subnet2 sai - 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]
Re: [pfSense Support] Firewall Rule Help?
I'll post the config file a little later today, when I get to my test box. In the mean time, I want to make it clear that subnet 2 is not directly connected to the pfsense box. Currently, the pfsense box has 4 interfaces: a Lan interface which is connected to subnet 1, a Wan interface, and 2 Opt interfaces. Opt 1 is called ATTDSL. This interface is the point of internet contact for a proxy server that lives on subnet 1 and was configured for this usage via a firewall rule as described in the policy routing tutorial on the pfsense website. The second Opt interface is called Wireless and will be used to test external VPN connections between offices via 802.11 access points. Subnet 2 is not directly physically connected to the pfsense box. An openSuse router sits between subnet 1 and subnet 2 and handles routing between these two subnets. A review of the symptoms of the problem that I'm having is that when I replace the pfsense with a linksys RV series router or Hotbrick router, both subnet 1 and subnet 2 are able to access the internet and to ping the router. When the pfsense box is in place, even with explicit rules allowing all traffic to all locations from the entire 192.168.0.0/16 network on the LAN interface, the pfsense box explicitly denies and logs all traffic trying to pass to it or through it from subnet 2. Vaughn sai wrote: On 3/18/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I have a pfsense firewall in a test network like the one below. Internet provider 1 | | provider 2 Pfsense Firewall -- LAN IP 192.168.10.1/24 | Subnet 1 -- 192.168.10.x/24 | Internal Router -- Subnet 1 IP 192.168.10.14 -- Subnet 2 IP 192.168.12.1 | Subnet 2 192.168.12.x/24 I am having trouble getting the clients on Subnet 2 to get access to either the Internet or to the interface of the pfsense box. I have the following rules entered into the firewall and NAT: Firewall: LAN Allow * from 192.168.0.0/16 to * NAT: Do Outbound NAT on 192.168.0.0/16 Here are the symptoms of the problem that I'm having. When I try to ping or connect to the pfsense box from subnet 1, I can ping and connect to it without any problems. When I try to ping or connect to it from subnet 2, the connection is refused. In addition, I can connect to Internet resources normally from subnet 1, but not from subnet 2. I thought that maybe the internal router was the problem, so I replaced the pfsense box with an el-cheapo router and everything worked correctly from both subnets without any changes to the internal router. I have also tried specifying allow rules for each subnet in the pfsense firewall rules page, but that seemed to have no effect. I am using the March 18th, 2007 daily build of the pfsense stable. I also noticed that the firewall log on the pfsense box is logging that it is dropping everything that is coming to it from subnet 2. If anyone can help me come up with a solution, I'd appreciate it. Thanks, Vaughn Firewall Rules add a rule for the subnet2 interface that allows the traffic. post the config for the interface and also the firewall rules for subnet2 sai - 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] Firewall Rule Help?
I have a pfsense firewall in a test network like the one below. Internet provider 1 | | provider 2 Pfsense Firewall -- LAN IP 192.168.10.1/24 | Subnet 1 -- 192.168.10.x/24 | Internal Router -- Subnet 1 IP 192.168.10.14 -- Subnet 2 IP 192.168.12.1 | Subnet 2 192.168.12.x/24 I am having trouble getting the clients on Subnet 2 to get access to either the Internet or to the interface of the pfsense box. I have the following rules entered into the firewall and NAT: Firewall: LAN Allow * from 192.168.0.0/16 to * NAT: Do Outbound NAT on 192.168.0.0/16 Here are the symptoms of the problem that I'm having. When I try to ping or connect to the pfsense box from subnet 1, I can ping and connect to it without any problems. When I try to ping or connect to it from subnet 2, the connection is refused. In addition, I can connect to Internet resources normally from subnet 1, but not from subnet 2. I thought that maybe the internal router was the problem, so I replaced the pfsense box with an el-cheapo router and everything worked correctly from both subnets without any changes to the internal router. I have also tried specifying allow rules for each subnet in the pfsense firewall rules page, but that seemed to have no effect. I am using the March 18th, 2007 daily build of the pfsense stable. I also noticed that the firewall log on the pfsense box is logging that it is dropping everything that is coming to it from subnet 2. If anyone can help me come up with a solution, I'd appreciate it. Thanks, Vaughn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Logoff Capability
I have posted a $400.00 USD bounty for implementing a logoff feature in the fourms. Also, I have added a $100.00 USD bonus for the implementation of a checkbox that will enable or disable https access via the WAN interface. Vaughn Reid III On Tue, 13 Feb 2007 00:54:27 +1100, Dave Hall [EMAIL PROTECTED] said: On Mon, 2007-02-12 at 07:32 -0500, Vaughn L. Reid III wrote: I'm not sure this is the correct forum for this sort of item, but I'll ask anyway. Is there any sort of extension available to provide a logoff capability from the web gui? I need this capability for HIPAA compliance. If not, how would I go about offering a bounty to get one implemented? Any coding that I sponsor and gets produced from this will be given back to the project lead for incorporation into the product. If anyone has any information or is interested in implementing this, please respond, and I'll provide contact information. As pfSense uses http authentication there is 2 easy options: 1 Close your browser when you are done 2 install the web developer toolbar extension for firefox and use the Misc Clear Private Data HTTP Authentication option This is a limitation of how browsers implement HTTP Authentication. bte I am not a pfSense developer, so someone else might have other ideas on how to deal with this. Cheers Dave -- L L*LLL L L DAVE L HALL CONSULTING Open Source Business Solutions p +61 410 47 42 55 e [EMAIL PROTECTED] w davehall.com.au f +61 3 8610 0029 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vaughn L. Reid III [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Pfsense Server Crash
I am experiencing the same problem with the daily snapshots as I am with the 1.0.1 release version. The following items cause the pfsense firewall to stop responding to anything: 1. Removing a static route 2. Doing anything in the Miscellaneous or Traffic Shaper and Firewall Advanced sections of Advanced System setup 3. Checking or unchecking the userland proxy box on any interface 4. Checking or unchecking Block Private Networks on the WAN interface page 5. Checking or unchecking Bogons Networks on the WAN interface page In addition, the firewall seems to stop working with any LAN side ethernet interface after adding or removing VPN tunnels. Any additional help would be appreciated. On Thu, 8 Feb 2007 00:29:09 -0500, Scott Ullrich [EMAIL PROTECTED] said: On 2/8/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: I have a pfsense firewall up and running with the following specs: 3.0 ghz Pentium IV processor 1 gigabyte of ECC (unregistered unbuffered) ram 1 40 gigabyte western digital hard drive Tyan entry level server motherboard with 2 onboard intel gigabyte network cards 2 dual port pci-x intel server gigabyte network cards (4 ports total between the two cards) 1 single port intel desktop gigabyte network card 1 hifn pci vpn accelerator card (from soekris engineering) I'm running psense 1.0.1 I have 2 dsl connections, and 3 lan connections. I have one port reserved for sync and one unused ethernet port. I've got about 50 users hitting the firewall on a regular basis and have approximately 5 vpn connections using ipsec and 2 pptp users. All of my ethernet cards use different irqs. The hifn card uses the same irq as one of the embedded ethernet cards. Here's the problem that I'm experiencing. When I try to perform some actions with the pfsense configuration, the machine simply stops responding. Rebooting does not help. Even though the network stops responding and even though the web gui stops responding, I can still log onto the system from the console and it appears that everything is working correctly. Specifically, the logs seem normal, ifconfig returns the expected values and show that the interfaces are up. The system just won't respond to pings, won't route or forward or filter traffic, and won't allow access to the web gui. The only way that I can seem to fix the problem is to re-install pfsense from cd and then reload my configuration file. Most actions don't cause this. For example adding nat and firewall rules, setting up pptp and ipsec connections, doing things with the dhcp server and dns forwarder seem to work normally. But, specifically I have found the following items cause the lock-up for lack of a better work. Trying to change anything under the advanced system tab that is in under the sub heading of Traffic Shaper and Firewall Advanced and trying to check or uncheck Block private networks or bogon networks on the wan tab seems to cause this behavior. Also attempting to check or uncheck the Disable the userland FTP-Proxy application on any interface seems to cause the behavior noted above. If anyone can provide some insight into this, I'd appreciate it. I've done some searching on my own of the forums and the existing documentation, but I can't seem to find anything that answers my questions. Please try a recent snapshot that is based on FreeBSD 6.2. More information can be found here. http://pfsense.blogspot.com/2007/01/102-beta-period-will-start-soon-5-9s.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vaughn L. Reid III [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Pfsense Server Crash
is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 arplookup 192.168.10.1 failed: host is not on local network arpresolve: can't allocate route for 192.168.10.1 em0: link state changed to DOWN em0: link state changed to UP arplookup 192.168.10.102 failed: host is not on local network arplookup 192.168.10.39 failed: host is not on local network arplookup 192.168.10.253 failed: host is not on local network arplookup 192.168.10.253 failed: host is not on local network arplookup 192.168.10.33 failed: host is not on local network arplookup 192.168.10.61 failed: host is not on local network arplookup 192.168.10.37 failed: host is not on local network em0: link state changed to DOWN em0: link state changed to UP WARNING: pseudo-random number generator used for IPsec processing em1: link state changed to DOWN em1: link state changed to UP On Fri, 09 Feb 2007 10:51:55 -0500, Vaughn L. Reid III [EMAIL PROTECTED] said: I am experiencing the same problem with the daily snapshots as I am with the 1.0.1 release version. The following items cause the pfsense firewall to stop responding to anything: 1. Removing
[pfSense Support] Pfsense Server Crash
I have a pfsense firewall up and running with the following specs: 3.0 ghz Pentium IV processor 1 gigabyte of ECC (unregistered unbuffered) ram 1 40 gigabyte western digital hard drive Tyan entry level server motherboard with 2 onboard intel gigabyte network cards 2 dual port pci-x intel server gigabyte network cards (4 ports total between the two cards) 1 single port intel desktop gigabyte network card 1 hifn pci vpn accelerator card (from soekris engineering) I'm running psense 1.0.1 I have 2 dsl connections, and 3 lan connections. I have one port reserved for sync and one unused ethernet port. I've got about 50 users hitting the firewall on a regular basis and have approximately 5 vpn connections using ipsec and 2 pptp users. All of my ethernet cards use different irqs. The hifn card uses the same irq as one of the embedded ethernet cards. Here's the problem that I'm experiencing. When I try to perform some actions with the pfsense configuration, the machine simply stops responding. Rebooting does not help. Even though the network stops responding and even though the web gui stops responding, I can still log onto the system from the console and it appears that everything is working correctly. Specifically, the logs seem normal, ifconfig returns the expected values and show that the interfaces are up. The system just won't respond to pings, won't route or forward or filter traffic, and won't allow access to the web gui. The only way that I can seem to fix the problem is to re-install pfsense from cd and then reload my configuration file. Most actions don't cause this. For example adding nat and firewall rules, setting up pptp and ipsec connections, doing things with the dhcp server and dns forwarder seem to work normally. But, specifically I have found the following items cause the lock-up for lack of a better work. Trying to change anything under the advanced system tab that is in under the sub heading of Traffic Shaper and Firewall Advanced and trying to check or uncheck Block private networks or bogon networks on the wan tab seems to cause this behavior. Also attempting to check or uncheck the Disable the userland FTP-Proxy application on any interface seems to cause the behavior noted above. If anyone can provide some insight into this, I'd appreciate it. I've done some searching on my own of the forums and the existing documentation, but I can't seem to find anything that answers my questions. Thanks, Vaughn Reid III Indiana USA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
