You should really disable this check and add the rules manually afterward. I use this configuration on wireless hotspots with wireless nics bridged to the wan. It works excellent. I only gave so much detail cos I found that the wrap boards can be a little funny changing that much and liked to be rebooted.
I am sure a pc config would work much better. Without the unplugs and so on. I just tested this today, a filtered bridge to a vpn concentrator and it works fine. > -----Original Message----- > From: Peter Zaitsev [mailto:[EMAIL PROTECTED] > Sent: 24 October 2005 23:19 > To: [email protected] > Subject: RE: [pfSense Support] pfsense 0.88 > > On Mon, 2005-10-24 at 15:00 +0100, alan walters wrote: > > Alan, > > First I should say it is not solid or user friendly if you have to wait > for given amount of time and then reboot the box. I think changes ether > have to be applied at once or interface should tell you reboot is > needed. > > I've just tired your approach. > > Removing IP from LAN at first does not remove it at once (interface is > still accessible by removed IP even after apply changes) > > Next after few minutes error appears in ticker about error loading > rules.debug - The problem is in "wanspoof" rule which becomes > /29 instead of 111.111.111.152/29 > > After reboot I get different behavior. Now I can access the box via WAN > but LAN does not see bridged IP. > > Also even after restart I have similar error > > php: : There were error(s) loading the rules: /tmp/rules.debug:62: > syntax error /tmp/rules.debug:95: syntax error /tmp/rules.debug:102: > syntax error pfctl: Syntax error in config file: pf rules not loaded - > The line in question reads [62]: block in log quick on em0 from /29 to > any label "WAN spoof check" > > > Here are appropriate lines from rules.debug > > # WAN spoof check > anchor "wanspoof" > LINE 62: block in log quick on em0 from /29 to any label "WAN spoof > check" > > > # make sure the user cannot lock himself out of the webGUI or SSH > anchor "anti-lockout" > LINE 95: pass in quick from /29 to keep state label "anti-lockout web > rule" > > # User-defined rules follow > LINE 102: pass in quick on $lan from /29 to any keep state label > "USER_RULE: Default LAN -> any" > > > This looks to me as rule generation script is broken for this case. > > Might be it was working in your version but is broken in 0.89.2 now. > > > > > I have a similar configuration where the lan is bridged to the wan. > > I just made a rule to allow access to the wan IP. This is accessable > > from anywhere as the bridge is in place. > > > > Configuration. > > > > Start with a clean install. > > Setup ip address in wan. Gateway etc. > > Configure firewall rules access wan IP from https and ssh > > Ie: allow all to wan port 443 etc. > > > > Setup allow rules for your other services. > > > > If the block is a private block you will have to turn off > > Block private blocks etc on wan interface. > > > > Disable dhcp server on lan > > > > Save the config. Incase it fails. > > > > Then remove ip address from lan and bridge it to wan. > > > > Wait a couple of minutes. Manually restart the box and access the wan ip > > address. > > > > All works fine for me in about 10 setups. > > > > > > > > > -----Original Message----- > > > From: Bill Marquette [mailto:[EMAIL PROTECTED] > > > Sent: 24 October 2005 14:45 > > > To: [email protected] > > > Subject: Re: [pfSense Support] pfsense 0.88 > > > > > > Anyone that's set this up care to comment? I'm starting to talk about > > > things I've never done, not a good idea :) > > > > > > --Bill > > > > > > On 10/24/05, Peter Zaitsev <[EMAIL PROTECTED]> wrote: > > > > On Sun, 2005-10-23 at 09:23 -0500, Bill Marquette wrote: > > > > > O > > > > > > > > > > > Is there any way I could have pfsense ip at .154 and use > > .155-158 > > > for > > > > > > my applications ? > > > > > > > > > > Yes, configure the pfSense LAN IP to .154 (and configure it for > > the > > > > > full subnet - you'll need to set the default gateway too) and then > > > > > bridge LAN to WAN. You'll need rules on the WAN interface to > > allow > > > > > for remote management of the pfSense box, but that should work > > just > > > > > fine. > > > > > > > > Well, > > > > > > > > Both LAN and WAN wants their IPs set. > > > > > > > > And never of configurations seems to work decent way. > > > > > > > > First, I have to set IP address to WAN network, otherwise it > > complains > > > > > > > > "field 'IP address' is required." > > > > > > > > I may only set IP to WAN network and leave LAN ip empty and enable > > > > bridging. In this case PfSense however becomes unreachable from > > LAN > > > > network (should not it be fixed to also require IP if it is really > > > > required ?) In this case I however can access WebGUI from > > external > > > > network (I allowed all incoming traffic for tests). > > > > > > > > One more bug around it - If I provide empty LAN address in > > configuration > > > > it continues to work... until reboot. Reboot causes system to be > > > > inaccessible from LAN. This especially worries me as if reboot > > happens > > > > few months after you've done some changes you might not remember > > what > > > > they were... > > > > > > > > > > > > If I set both LAN and WAN to use the same IP address (.154) access > > from > > > > WAN breaks, even with firewall which permits everything > > > > > > > > ... Went do do some research. > > > > > > > > Ok. It looks like I got what the problem is. There is "wanspoof" > > rule > > > > which blocks all traffic from WAN network which comes from IPs which > > are > > > > set for LAN network, which seems to be wrong in case of Network > > > > bridging. > > > > > > > > Also... I see there is the rule "SSHLockout" - any way to disable > > it ? > > > > It is to be used in collocation environment and there are certain > > hosts > > > > which will need such access. > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > 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]
