[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] ntop package on 03-27 snapshot
I know it's not much, but you've certainly proven that ntop is not running. My only other suggestion is to look at StatusSystem LogsSystem, particularly right after stopping and starting ntop. ntop creates numerous entries in the system log when it starts (or attempts to), and you may find some log entries that point to the problem's source. I assume you are aware of ntop's site, ntop.org? If you get some log entries to work with, you may be able to use them to find a solution at ntop.org. If you can get it operational, it really is a useful probe tool. -Original Message- From: Dimitri Rodis [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 6:37 PM To: support@pfsense.com Subject: RE: [pfSense Support] ntop package on 03-27 snapshot I see no mention of ntop, yet the package installer insists that it is installed (and if I uninstall/reinstall, it states that it started the service successfully) $ ps -A PID TT STAT TIME COMMAND 0 ?? WLs0:00.00 [swapper] 1 ?? ILs0:00.00 /sbin/init -- 2 ?? DL 0:00.00 [crypto] 3 ?? DL 0:00.00 [crypto returns] 4 ?? DL 0:00.52 [g_event] 5 ?? DL 0:00.76 [g_up] 6 ?? DL 0:00.74 [g_down] 7 ?? DL 0:00.00 [thread taskq] 8 ?? DL 0:00.00 [acpi_task_0] 9 ?? DL 0:00.00 [acpi_task_1] 10 ?? RL 105:42.57 [idle: cpu0] 11 ?? WL 1:33.57 [swi4: clock sio] 12 ?? WL 0:00.00 [swi3: vm] 13 ?? WL 0:00.19 [swi1: net] 14 ?? DL 0:00.44 [yarrow] 15 ?? WL 0:05.90 [swi6: task queue] 16 ?? WL 0:00.00 [swi6: Giant taskq] 17 ?? DL 0:00.00 [acpi_task_2] 18 ?? WL 0:00.00 [swi5: +] 19 ?? DL 0:00.00 [kqueue taskq] 20 ?? WL 0:00.00 [swi2: cambio] 21 ?? WL 0:00.00 [irq9: acpi0] 22 ?? WL 0:00.00 [irq16: uhci0] 23 ?? DL 0:00.00 [usb0] 24 ?? DL 0:00.00 [usbtask] 25 ?? WL 0:00.02 [irq19: sf0 uhci1] 26 ?? DL 0:00.00 [usb1] 27 ?? WL 1:52.96 [irq18: xl0 em0+] 28 ?? DL 0:00.00 [usb2] 29 ?? WL 0:00.00 [irq23: ehci0] 30 ?? DL 0:00.00 [usb3] 31 ?? WL 0:00.20 [irq14: ata0] 32 ?? WL 0:00.00 [irq15: ata1] 33 ?? DL 0:00.05 [fdc0] 34 ?? WL 0:00.00 [irq1: atkbd0] 35 ?? WL 0:00.00 [irq12: psm0] 36 ?? WL 0:00.00 [swi0: sio] 37 ?? WL 0:00.00 [irq7: ppc0] 38 ?? DL 0:00.01 [pagedaemon] 39 ?? DL 0:00.00 [vmdaemon] 40 ?? RL 0:00.01 [idlepoll] 41 ?? RL 0:01.76 [pagezero] 42 ?? DL 0:00.06 [bufdaemon] 43 ?? DL 0:00.39 [syncer] 44 ?? DL 0:00.05 [vnlru] 45 ?? DL 0:00.08 [softdepflush] 46 ?? DL 0:00.63 [schedcpu] 53 ?? DL 0:00.04 [md0] 112 ?? Is 0:00.01 /sbin/devd 183 ?? Ss 0:00.05 /usr/sbin/syslogd -s -f /var/etc/syslog.conf 530 ?? R 0:00.95 /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfig 531 ?? Is 0:00.02 /usr/local/bin/php 533 ?? I 0:00.50 /usr/local/bin/php 549 ?? Is 0:00.02 /usr/local/bin/php 554 ?? S 0:02.34 /usr/local/bin/php 562 ?? I 0:00.00 /usr/local/sbin/dnsmasq 638 ?? Ss 0:00.06 /usr/local/sbin/pftpx -q qP2PDown -c 8021 -g 8021 10. 646 ?? Ss 0:00.24 /usr/local/sbin/ftpsesame -q qP2PDown -i em0 649 ?? Ss 0:00.40 /usr/local/sbin/ftpsesame -q qP2PDown -i bridge0 826 ?? Ss 0:00.02 ntpd: [priv] (ntpd) 829 ?? Is 0:00.04 /usr/sbin/cron -s 845 ?? Is 0:00.01 minicron 240 /var/run/ping_hosts.pid /etc/ping_hosts. 853 ?? Is 0:00.01 /usr/local/sbin/sshlockout_pf 12241 ?? ZN 0:00.02 defunct 12247 ?? IN 0:00.00 /bin/sh /var/db/rrd/updaterrd.sh 12248 ?? RN80:16.29 pfctl -vsq 12249 ?? IN 0:00.00 [awk] 13577 ?? S 0:00.00 sh -c ps -A 13578 ?? R 0:00.00 ps -A 852 v0 Is 0:00.02 login [pam] (login) 854 v0 I 0:00.01 -sh (sh) 855 v0 I+ 0:00.01 /bin/sh /etc/rc.initial 306 con- S 0:00.25 /usr/sbin/tcpdump -l -n -e -ttt -i pflog0 307 con- I 0:00.00 logger -t pf -p local0.info 718 con- IN 0:01.07 /bin/sh /var/db/rrd/updaterrd.sh 825 con- I 0:00.19 ntpd: ntp engine (ntpd) 841 con- SN 0:00.86 /usr/local/sbin/check_reload_status $ netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 15310 pfsense.https (removed) ESTABLISHED tcp4 0 0 localhost.ftp-proxy*.* LISTEN tcp6 0 0 *.domain *.* LISTEN tcp4 0 0 *.domain *.* LISTEN tcp4 0 0 *.https*.* LISTEN udp4 0 0 spanishtrails2.w.65060 dedibox.bitschin.ntp udp4 0 0 spanishtrails2.w.61789 trane.wu-wien.ac.ntp udp4 0 0 spanishtrails2.w.54543 www.icewarm.com..ntp udp4 0 0
Re: [pfSense Support] Connectivity Issue with second OPT interface
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]
[pfSense Support] Error Message Adding 1-1 NAT entry for OPT3
Here is the message that I am receiving. Robert There were error(s) loading the rules: /tmp/rules.debug:54: macro 'opt3' not defined/tmp/rules.debug:54: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [54]: binat on $opt3 from 10.0.0.51/32 to any - 74.95.24.50/32... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC over an OPT interface Problems
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]
Re: [pfSense Support] Connectivity Issue with second OPT interface
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]
Re: [pfSense Support] Error Message Adding 1-1 NAT entry for OPT3
Is the interface enabled? On 3/29/07, Robert Goley [EMAIL PROTECTED] wrote: Here is the message that I am receiving. Robert There were error(s) loading the rules: /tmp/rules.debug:54: macro 'opt3' not defined/tmp/rules.debug:54: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [54]: binat on $opt3 from 10.0.0.51/32 to any - 74.95.24.50/32... - 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] Connectivity Issue with second OPT interface
I know it works. You guys have done great with that. I have WAN, OPT1, and OPT2 working great. I do not know why OPT3 and OPT4 do not. I have tested and checked so much I don't know what else to look for. I have not seen this specific doc. I don't think it existed when I set this up originally. I will go over this one too. Robert On Thursday 29 March 2007 11:08, 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]
[pfSense Support] Multi-Wan/Load Balancing
Hi All, I´m folowing the documentation (http://doc.pfsense.org/index.php/Multi-Wan/Load-Balancing) to setup a Multi-Wan/Load Balancing environment, however after create the pool, I´m getting a error when I click on Apply button: Warning: unlink(/tmp/Wan1BalanceWan2.pool): No such file or directory in /etc/inc/vslb.inc on line 104 WAN and OPT1 is current using static IP´s. WAN is using fxp module and OPT1 is using xl module. 1.0.1-SNAPSHOT-03-15-2007 built on Fri Mar 23 05:07:13 EDT 2007 -- Diego - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Multi-Wan/Load Balancing
On 3/29/07, Diego Morato [EMAIL PROTECTED] wrote: Hi All, I´m folowing the documentation (http://doc.pfsense.org/index.php/Multi-Wan/Load-Balancing) to setup a Multi-Wan/Load Balancing environment, however after create the pool, I´m getting a error when I click on Apply button: Warning: unlink(/tmp/Wan1BalanceWan2.pool): No such file or directory in /etc/inc/vslb.inc on line 104 WAN and OPT1 is current using static IP´s. WAN is using fxp module and OPT1 is using xl module. Thanks for the report. It is cosmetic only and should now be fixed. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Incoming FTP Traffic To Wrong Queue
On 3/28/07, Mark Kane [EMAIL PROTECTED] wrote: The latest snapshot seems to be the same as the previous one (still going to qlandef but doesn't seem to affect other traffic much). 1.0.1-SNAPSHOT-03-27-2007 built on Wed Mar 28 21:01:28 EDT 2007 # ps awux | grep pftpx proxy550 0.0 0.1 656 420 ?? Is 10:23PM 0:00.04 /usr/local/sbin/pftpx -q qlandef -c 8021 -g 8021 192.168.1.1 root1492 0.0 0.2 1552 660 p0 R+ 10:26PM 0:00.01 grep pftpx Please open Diagnostics - Command Prompt and in the PHP command box type in: echo isset($config['ezshaper']['step5']['p2pcatchall']); And: print_r($config['ezshaper']); And please paste the results. Thanks! Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Multi-Wan/Load Balancing
Ok, thank you. I will test this and report any problems. Diego - Original Message - From: Scott Ullrich [EMAIL PROTECTED] To: support@pfsense.com Sent: Thursday, March 29, 2007 1:25 PM Subject: Re: [pfSense Support] Multi-Wan/Load Balancing On 3/29/07, Diego Morato [EMAIL PROTECTED] wrote: Hi All, I´m folowing the documentation (http://doc.pfsense.org/index.php/Multi-Wan/Load-Balancing) to setup a Multi-Wan/Load Balancing environment, however after create the pool, I´m getting a error when I click on Apply button: Warning: unlink(/tmp/Wan1BalanceWan2.pool): No such file or directory in /etc/inc/vslb.inc on line 104 WAN and OPT1 is current using static IP´s. WAN is using fxp module and OPT1 is using xl module. Thanks for the report. It is cosmetic only and should now be fixed. 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] 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] Adding OPT3 and OPT4 WAN connections
On 3/28/07, Robert Goley [EMAIL PROTECTED] wrote: I have 1 existing DSL connection and 2 existing Cable connections. I am adding 2 more Cable connections as part of a phase-in/phase-out scenario. The current setup works great. It is using policy based routing on pfsense 1.0.1. I can not seem to get the additional interfaces to work. I have tested with my laptop and know the the ISP routers are setup and working correctly as bridges. On my laptop, all I have to do is enter the correct static IP information to use the internet. The ISP threw me off a little setting the router IP as the highest number in the assigned IP range. All other ISPs have used the lowest. I am not sure how to enter the static IP info for the OPTx interfaces because of this. I have been assigned x.x.x.49-x.x.x.53 with the default gateway being x.x.x.54. It is a /29 netblock with netmask 255.255.255.248. Would I enter this as x.x.x.49/29, x.x.x.53/29, or x.x.x.54/29? I am not getting any traffic thru the interface when I have tried using these. I setup a port forward for SSH to a test machine on the network. It does not go thru. Is there a default traffic rule I have missed adding somewhere? Any information you can provide would be appreciated. Robert Use the same settings that you got working on your laptop? Can you ping the gateway in question from the pfsense firewall? sai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Incoming FTP Traffic To Wrong Queue
On Thu, Mar 29, 2007, at 12:29:37 -0400, Scott Ullrich wrote: Please open Diagnostics - Command Prompt and in the PHP command box type in: echo isset($config['ezshaper']['step5']['p2pcatchall']); This didn't return anything. And: print_r($config['ezshaper']); Array ( [step2] = Array ( [download] = 5120 [upload] = 615 [inside_int] = lan [outside_int] = wan ) [step3] = Array ( [enable] = on [provider] = Generic [address] = VoIP [bandwidth] = 384 ) [step6] = Array ( [msrdp] = [vnc] = [appleremotedesktop] = [pcanywhere] = [irc] = [jabber] = [icq] = [aolinstantmessenger] = [msnmessenger] = [teamspeak] = [pptp] = [ipsec] = [streamingmp3] = [rtsp] = [http] = [smtp] = [pop3] = [imap] = [lotusnotes] = [dns] = [icmp] = [smb] = [snmp] = [mysqlserver] = [nntp] = [cvsup] = ) [step4] = Array ( [p2pcatchall] = on [enable] = on ) ) Thanks. -Mark -- Internet Radio: Party107 (Trance/Electronic) - http://www.party107.com Rock 101.9 The Edge (Rock) - http://www.rock1019.net IRC: MIXXnet IRC Network - irc.mixxnet.net (Nick: MIXX941) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] IPSEC over an OPT interface Problems
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]
Re: [pfSense Support] Incoming FTP Traffic To Wrong Queue
P2PCatch all is not enabled then. Here is what my host shows: # php -f test.php 1 Array ( [step2] = Array ( [download] = 3000 [upload] = 250 [inside_int] = lan [outside_int] = wan ) [step3] = Array ( [provider] = Generic [address] = [bandwidth] = 32 ) [step4] = Array ( [address] = [bandwidthup] = [bandwidthdown] = ) [step5] = Array ( [bandwidthup] = [bandwidthdown] = [enable] = on [p2pcatchall] = on ) [step7] = Array ( [msrdp] = [vnc] = [appleremotedesktop] = [pcanywhere] = [irc] = [jabber] = [icq] = [aolinstantmessenger] = [msnmessenger] = [teamspeak] = [pptp] = [ipsec] = [streamingmp3] = [rtsp] = [http] = [smtp] = [pop3] = [imap] = [lotusnotes] = [dns] = [icmp] = [smb] = [snmp] = [mysqlserver] = [nntp] = [cvsup] = ) [step6] = Array ( [enable] = on [counterstrike] = on ) ) Revisit the traffic shaping wizard, on the Peer to Peer networking screen check Lower priority of Peer-to-Peer traffic and then check p2pCatchAll. Scott Scott On 3/29/07, Mark Kane [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007, at 12:29:37 -0400, Scott Ullrich wrote: Please open Diagnostics - Command Prompt and in the PHP command box type in: echo isset($config['ezshaper']['step5']['p2pcatchall']); This didn't return anything. And: print_r($config['ezshaper']); Array ( [step2] = Array ( [download] = 5120 [upload] = 615 [inside_int] = lan [outside_int] = wan ) [step3] = Array ( [enable] = on [provider] = Generic [address] = VoIP [bandwidth] = 384 ) [step6] = Array ( [msrdp] = [vnc] = [appleremotedesktop] = [pcanywhere] = [irc] = [jabber] = [icq] = [aolinstantmessenger] = [msnmessenger] = [teamspeak] = [pptp] = [ipsec] = [streamingmp3] = [rtsp] = [http] = [smtp] = [pop3] = [imap] = [lotusnotes] = [dns] = [icmp] = [smb] = [snmp] = [mysqlserver] = [nntp] = [cvsup] = ) [step4] = Array ( [p2pcatchall] = on [enable] = on ) ) Thanks. -Mark -- Internet Radio: Party107 (Trance/Electronic) - http://www.party107.com Rock 101.9 The Edge (Rock) - http://www.rock1019.net IRC: MIXXnet IRC Network - irc.mixxnet.net (Nick: MIXX941) - 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] Adding OPT3 and OPT4 WAN connections
On Thursday 29 March 2007 13:46, sai wrote: Use the same settings that you got working on your laptop? Yes, same settings. Can you ping the gateway in question from the pfsense firewall? I did not think that you could ping because of default traffic rules going out on WAN and then back in from the internet. I do have states that show outbound connections working properly. I am preparing to completely rebuild the setup now. The docs that Scott provided show that the pfsense version is behind the times. It is 1.0.1 but a 11-29-2006 snapshot. I am hoping this upgrade will fix the 1-1 NAT error I emailed to the list earlier. sai - 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
No, this sounds like a bug. I sent a request for information a few minutes ago. Did you get it? If so please check /tmp/rules.debug for IPSEC and see if the OPT interface rules are being addded. On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: 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]
Re: [pfSense Support] IPSEC over an OPT interface Problems
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 the manual rules that I created first before checking? Yes, please. Then open up /tmp/rules.debug and look for VPN Rules.. Below that marker is the system generated IPSEC rules. Do you see entries for the OPT interface? Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Multi-Wan/Load Balancing
Hi again, I´ve just tested this funcionality and it works great! I just followed the documentation. Bellow are some info about my system. To test I unplug and plug the connection cables. Version: 1.0.1-SNAPSHOT-03-15-2007 built on Fri Mar 23 05:07:13 EDT 2007 system.log: Mar 29 14:54:32 server01 check_reload_status: rc.linkup starting Mar 29 15:04:34 server01 check_reload_status: reloading filter Mar 29 15:04:36 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:04:37 server01 slbd[72876]: ICMP poll succeeded for 204.xx.20.9, marking service UP Mar 29 15:04:39 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:04:41 server01 slbd[72876]: ICMP poll succeeded for 204.xx.20.9, marking service UP Mar 29 15:04:43 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:04:45 server01 slbd[72876]: ICMP poll succeeded for 204.xx.20.9, marking service UP Mar 29 15:04:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:06:02 server01 check_reload_status: reloading filter Mar 29 15:06:04 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:06:04 server01 php: : We found 2 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:06:04 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:06:04 server01 php: : Setting up route with opt1 om xl1 for monitor 200.xx.4.65 on gateway 200.xx.4.65 Mar 29 15:09:15 server01 check_reload_status: reloading filter Mar 29 15:09:17 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:09:17 server01 php: : We found 2 valid entries in status file /tmp/OPT1FailoverWAN.pool Mar 29 15:09:18 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:11:14 server01 check_reload_status: reloading filter Mar 29 15:11:15 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:12:37 server01 check_reload_status: reloading filter Mar 29 15:12:38 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:12:54 server01 check_reload_status: reloading filter Mar 29 15:12:56 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:12:57 server01 php: : We found 2 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:12:57 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:12:57 server01 php: : Setting up route with opt1 om xl1 for monitor 200.xx.4.65 on gateway 200.xx.4.65 Mar 29 15:15:13 server01 kernel: xl1: link state changed to DOWN Mar 29 15:15:15 server01 slbd[72876]: ICMP poll failed for 200.xx.4.65, marking service DOWN Mar 29 15:15:15 server01 slbd[72876]: Service OPT1FailoverWAN changed status, reloading filter policy Mar 29 15:15:15 server01 slbd[72876]: ICMP poll failed for 200.xx.4.65, marking service DOWN Mar 29 15:15:15 server01 slbd[72876]: Service WANFailoverOPT1 changed status, reloading filter policy Mar 29 15:15:15 server01 slbd[72876]: ICMP poll failed for 200.xx.4.65, marking service DOWN Mar 29 15:15:15 server01 slbd[72876]: Service WanBalanceOPT1 changed status, reloading filter policy Mar 29 15:15:17 server01 check_reload_status: reloading filter Mar 29 15:15:20 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:15:20 server01 php: : We found 1 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:15:20 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:19:09 server01 kernel: xl1: link state changed to UP Mar 29 15:19:11 server01 kernel: xl1: link state changed to DOWN Mar 29 15:19:11 server01 check_reload_status: rc.linkup starting Mar 29 15:19:14 server01 kernel: xl1: link state changed to UP Mar 29 15:19:18 server01 check_reload_status: rc.linkup starting Mar 29 15:19:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:19:47 server01 slbd[72876]: Service OPT1FailoverWAN changed status, reloading filter policy Mar 29 15:19:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:19:47 server01 slbd[72876]: Service WANFailoverOPT1 changed status, reloading filter policy Mar 29 15:19:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:19:47 server01 slbd[72876]: Service WanBalanceOPT1 changed status, reloading filter policy Mar 29 15:19:50 server01 check_reload_status: reloading filter Mar 29 15:19:52 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:19:52 server01 php: : We found 2 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:19:53 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on
Re: [pfSense Support] Multi-Wan/Load Balancing
Great! Glad that you got it working and that validates the documentation's ability. Scott On 3/29/07, Diego Morato [EMAIL PROTECTED] wrote: Hi again, I´ve just tested this funcionality and it works great! I just followed the documentation. Bellow are some info about my system. To test I unplug and plug the connection cables. Version: 1.0.1-SNAPSHOT-03-15-2007 built on Fri Mar 23 05:07:13 EDT 2007 system.log: Mar 29 14:54:32 server01 check_reload_status: rc.linkup starting Mar 29 15:04:34 server01 check_reload_status: reloading filter Mar 29 15:04:36 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:04:37 server01 slbd[72876]: ICMP poll succeeded for 204.xx.20.9, marking service UP Mar 29 15:04:39 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:04:41 server01 slbd[72876]: ICMP poll succeeded for 204.xx.20.9, marking service UP Mar 29 15:04:43 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:04:45 server01 slbd[72876]: ICMP poll succeeded for 204.xx.20.9, marking service UP Mar 29 15:04:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:06:02 server01 check_reload_status: reloading filter Mar 29 15:06:04 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:06:04 server01 php: : We found 2 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:06:04 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:06:04 server01 php: : Setting up route with opt1 om xl1 for monitor 200.xx.4.65 on gateway 200.xx.4.65 Mar 29 15:09:15 server01 check_reload_status: reloading filter Mar 29 15:09:17 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:09:17 server01 php: : We found 2 valid entries in status file /tmp/OPT1FailoverWAN.pool Mar 29 15:09:18 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:11:14 server01 check_reload_status: reloading filter Mar 29 15:11:15 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:12:37 server01 check_reload_status: reloading filter Mar 29 15:12:38 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:12:54 server01 check_reload_status: reloading filter Mar 29 15:12:56 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:12:57 server01 php: : We found 2 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:12:57 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:12:57 server01 php: : Setting up route with opt1 om xl1 for monitor 200.xx.4.65 on gateway 200.xx.4.65 Mar 29 15:15:13 server01 kernel: xl1: link state changed to DOWN Mar 29 15:15:15 server01 slbd[72876]: ICMP poll failed for 200.xx.4.65, marking service DOWN Mar 29 15:15:15 server01 slbd[72876]: Service OPT1FailoverWAN changed status, reloading filter policy Mar 29 15:15:15 server01 slbd[72876]: ICMP poll failed for 200.xx.4.65, marking service DOWN Mar 29 15:15:15 server01 slbd[72876]: Service WANFailoverOPT1 changed status, reloading filter policy Mar 29 15:15:15 server01 slbd[72876]: ICMP poll failed for 200.xx.4.65, marking service DOWN Mar 29 15:15:15 server01 slbd[72876]: Service WanBalanceOPT1 changed status, reloading filter policy Mar 29 15:15:17 server01 check_reload_status: reloading filter Mar 29 15:15:20 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:15:20 server01 php: : We found 1 valid entries in status file /tmp/WanBalanceOPT1.pool Mar 29 15:15:20 server01 php: : Setting up route with wan om fxp0 for monitor 204.xx.20.9 on gateway 204.xx.20.9 Mar 29 15:19:09 server01 kernel: xl1: link state changed to UP Mar 29 15:19:11 server01 kernel: xl1: link state changed to DOWN Mar 29 15:19:11 server01 check_reload_status: rc.linkup starting Mar 29 15:19:14 server01 kernel: xl1: link state changed to UP Mar 29 15:19:18 server01 check_reload_status: rc.linkup starting Mar 29 15:19:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:19:47 server01 slbd[72876]: Service OPT1FailoverWAN changed status, reloading filter policy Mar 29 15:19:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:19:47 server01 slbd[72876]: Service WANFailoverOPT1 changed status, reloading filter policy Mar 29 15:19:47 server01 slbd[72876]: ICMP poll succeeded for 200.xx.4.65, marking service UP Mar 29 15:19:47 server01 slbd[72876]: Service WanBalanceOPT1 changed status, reloading filter policy Mar 29 15:19:50 server01 check_reload_status: reloading filter Mar 29 15:19:52 server01 php: : Filter: FTP proxy disabled for interface opt1 - ignoring. Mar 29 15:19:52 server01 php: : We found 2 valid entries in status file
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 the
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 the
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
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 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
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
Okay, I see this bug as well. Will get it fixed soon. Scott On 3/29/07, Scott Ullrich [EMAIL PROTECTED] 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 from port 20 to (em1) port 49000 user proxy flags S/SA keep state label FTP PROXY: PASV mode data
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
On 3/29/07, Vaughn L. Reid III [EMAIL PROTECTED] wrote: Thanks for your hard work. I appreciate it and I'm sure my customers do too. No problem, the bug should be fixed now. Please test a snapshot about 1-2 hours from now. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Web interface errors
I am entering the failover and load balancing rules. Rules look fine. Should there be blank rules there by default? There is one for the load balance and one for the pools. Robert Warning: unlink(/tmp/.pool): No such file or directory in /etc/inc/vslb.inc on line 58 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: unlink(/tmp/FailOverOPT2WAN.pool): No such file or directory in /etc/inc/vslb.inc on line 104 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Web interface errors
This was fixed earlier. Scott On 3/29/07, Robert Goley [EMAIL PROTECTED] wrote: I am entering the failover and load balancing rules. Rules look fine. Should there be blank rules there by default? There is one for the load balance and one for the pools. Robert Warning: unlink(/tmp/.pool): No such file or directory in /etc/inc/vslb.inc on line 58 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: unlink(/tmp/FailOverOPT2WAN.pool): No such file or directory in /etc/inc/vslb.inc on line 104 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 Warning: stristr(): Empty delimiter. in /etc/inc/pfsense-utils.inc on line 1227 - 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] Web interface errors
Was not sure if it wa the same error. Thanks for the fix. Robert On Thursday 29 March 2007 18:17, Scott Ullrich wrote: This was fixed earlier. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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] Incoming portfords fail/disappear
I have reworked the firewall according to the docs Scott provided. Most things are working fine. OPT1 and OPT2 using the new cable modems that had trouble earlier are working. WAN however is not working right. I am having a similar problem to earlier. With WAN set to be the default route, I can access the internet. I verified that this traffic is going out over thew WAN. I can not access either a NAT portforward or 1-1 NAT on this connection. I have log entries for this interface and related IP addresses with the exception of IP addresses mentioned in NAT mappings. First note is that every rule is set to log right now. There are firewall logs for x.x.x.142 but not for x.x.x.141 or x.x.x.140 which are setup for incoming NAT. I am able to use the port forwards for the OP1 and OPT2 interfaces. All three interfaces have 80% the same rules. There is no difference between them. I am willing to provide screen shots etc. Thank you for your time. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] bridged interface and arp: moved... messages
On Wed, 31 Jan 2007, Scott Ullrich wrote: On 1/31/07, Charles Sprickman [EMAIL PROTECTED] wrote: Hi all, I'm running PFSense 1.0.1 with three interfaces: WAN, LAN and then OPT1 acting as a bridged interface with the WAN. Our DSL provider gives us a /29 on the LAN port of their router and I use the first available IP for the PFSense WAN IP (which is also used for NAT on the LAN) and the remainder of the /29 bridges to OPT1. On the boxes connected to the bridge interface I periodically get the following messages in the logs: Jan 30 23:45:54 devel2 /kernel: arp: 74.x.x.26 moved from 00:50:ba:52:00:95 to 00:b0:d0:b6:94:3d on fxp0 Jan 30 23:47:21 devel2 /kernel: arp: 74.x.x.26 moved from 00:b0:d0:b6:94:3d to 00:50:ba:52:00:95 on fxp0 Jan 31 00:05:48 devel2 /kernel: arp: 74.x.x.26 moved from 00:50:ba:52:00:95 to 00:b0:d0:b6:94:3d on fxp0 The two MAC addresses in question are the WAN and OPT1 interfaces. I've seen some discussion of this on the freebsd-stable list, but no real good info. WAN is an rl card, OPT1 is an xl if that matters. Any ideas why the bridged hosts occasionally see the invisible MAC address of the OPT1 interface? It thinks there is some kind of loop somewhere. While I cannot certify your working environment without a lot more questions and answers which is beyond this mailing list I can tell you how to squash this message... System - Advanced - Shared Physical Network Sorry for returning to this so late... I think last time I got lost on a tangent of trying to find software to help draw ascii network diagrams and never came back... :) In short, here's the network. Pretty simple, no loops, very common setup for a US SDSL or routed ADSL customer with ISP-provided CPE: | ADSL w/routed /29 | +---|+ | router | ++ | 74.x.x.25 (network is 74.x.x.24/29) | | | WAN 74.x.x.26 - 00:50:ba:52:00:95 +---\+ |pfsense | +-/-\+ LAN / \ OPT1 (bridged w/WAN, ie: 74.x.x.24/29 (192.168.0.1/24 - nat) / \00:b0:d0:b6:94:3d) +--+ +-'+ |switch| |switch| +--+ +--+ | | | | workstations at | | | | 192.168.0.2-20 | |+--+ +--+ +--+ +--+ | | | | | | | | | | | | servers at 74.x.x.27, 74.x.x.28 | | | | | | | | (these report that 74.x.x.26 | | | | | | | | is moving) +--+ +--+ +--+ +--+ Does that clarify things? There is NO physical connection between the OPT1 and WAN networks, hence no loop. Thanks, Charles 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]
[pfSense Support] NAT Mapping failure
I did find that 1-1 mapping is breaking the outgoing connect of the machine that is being mapped. I verified this by switching a 1-1 NAT mapping between to machines. I was able to access before the map and could not after. on the other machine that had the map to start with, I could not access out. After switch the map to another machine I was able to access it from this machine. I have deleted all NAT port forward for the WAN interface and recreated 2 for testing SSH and HTTP. Neither work. The same portforwards for OPT1 and OPT2 work. The firewall rules were autocreated by pfSense. I an using any for the from IP addresses and ports. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Killing/Cutting off a TCP connection
Is there a way to kill/cut off an established TCP session without doing a reset all state? Thanks, Sally - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Killing/Cutting off a TCP connection
Yes, You have to explicitly kill the state from a terminal on the pfSense router. I have done it a few times in the past but can not remember the command at the moment. Search google for pf kill state. I will email the command if I find it. Robert On Thursday 29 March 2007 21:01, Sally Janghos wrote: Is there a way to kill/cut off an established TCP session without doing a reset all state? Thanks, Sally - 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] Killing/Cutting off a TCP connection
I found the command. Here are some basics on it. pfctl -k host Kill all of the state entries originating from the specified host. A second -k host option may be specified, which will kill all the state entries from the first host to the second host. For example, to kill all of the state entries originating from host: # pfctl -k host To kill all of the state entries from host1 to host2: # pfctl -k host1 -k host2 On Thursday 29 March 2007 21:01, Sally Janghos wrote: Is there a way to kill/cut off an established TCP session without doing a reset all state? Thanks, Sally - 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] Killing/Cutting off a TCP connection
On 3/29/07, Robert Goley [EMAIL PROTECTED] wrote: I found the command. Here are some basics on it. pfctl [snip] Newer snapshots can kill the states from Diagnostics - States without the command line. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] OpenVPN - Site-to-Site
May I confirm something? For site-to-site connection, it is always required that one pfsense operates as a server and one operates as a client, correct? server-to-server and client-to-client do nto work? Regards, Kelvin
RE: [pfSense Support] IPSEC over an OPT interface Problems
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: 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 -
RE: [pfSense Support] NAT Mapping failure
Please don't switch the topics of your mails concerning the same issue constantly. It's hard to follow/track a vonversation this way. Thank you. Holger -Original Message- From: Robert Goley [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 2:42 AM To: support@pfsense.com Subject: [pfSense Support] NAT Mapping failure I did find that 1-1 mapping is breaking the outgoing connect of the machine that is being mapped. I verified this by switching a 1-1 NAT mapping between to machines. I was able to access before the map and could not after. on the other machine that had the map to start with, I could not access out. After switch the map to another machine I was able to access it from this machine. I have deleted all NAT port forward for the WAN interface and recreated 2 for testing SSH and HTTP. Neither work. The same portforwards for OPT1 and OPT2 work. The firewall rules were autocreated by pfSense. I an using any for the from IP addresses and ports. - 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]
