How to assign Virtual IP for outbound to LAN Device?
-
Suggestion to Devs: I think a better option for both features would be to then keep everything Automatic unless a Manual rule is defined. In that case, there is no need for two modes and worrying about the risk of switching.
-
IMHO I prefer Manual outbound NAT in all cases because if you make a rule for everything that is passing out through WAN (and its easy) then you know for sure its all working and you can make little tweaks to them individually according to their purpose. Automatic outbound feels nice and safe, but now I wouldn't want anything other than manual.
Again… Its really not hard.
All it is a a simple statement of each subnet you want to be able to pass to the internet and you can omit any you don't want to have internet access.
That list is probably the loop-back address, each LAN and VPN subnet and thats all. -
I'm pretty sure you want to Make a pretty normal looking outbound NAT rule and then Stipulate the source as your LAN and then translation as one of your virtual IPs you have set up from your /27. (Move those rules to the top)
Anyone?
-
Exactly. Put in rules above the whole LAN subnet rule that catch traffic from specific internal IPs and translate it to specific external IPs.
It should be quite easy but I completely understand why Torotob is nervous if he doesn't have physical access to the box.Steve
-
I only administer 1 locally and the rest are all flung to the 4 corners. Literally.
I do not experiment with package loading and unloading like crazy on those and I only run release versions.But, I do update users, rules etc. Haven't had a lockout in years. Not one.
If you use the KISS approach with pfsense, its very very reliable.
But yeah - Locked out of a box on another continent would suck.
I assume that he has SSH enabled for access on the WAN? I really don't think he will break his box so bad even SSH can't get him a pfsense menu?
Not with a button press to switch to manual outbound NAT? -
I wish there was a roll-back (e.g. press the reset button on Alix to reset back the config to last 10 minutes for example) - then one could kiss good by to lockouts.
So, it seems that Manual outbound gives more control so why not MERGE automatic and manual together in future versions and allow the user to change rules when it's needed. So, what I am purposing is that DO CREATE an automatic rule every time but then allow the user to modify that without switch between Automatic and Manual. Just name it as OUTBOUND RULES.
Cheers
-
I wish there was a roll-back (e.g. press the reset button on Alix to reset back the config to last 10 minutes for example) - then one could kiss good by to lockouts.
If only it were that simple… though if you have console access to the alix, on 2.1 there is an option to restore an older config on the shell/console menu. It gives you a list and offers choices to restore.
So, it seems that Manual outbound gives more control so why not MERGE automatic and manual together in future versions and allow the user to change rules when it's needed. So, what I am purposing is that DO CREATE an automatic rule every time but then allow the user to modify that without switch between Automatic and Manual. Just name it as OUTBOUND RULES.
Already planned for 2.2: http://redmine.pfsense.org/issues/2416
It can't merge exactly as you say since that would be impossible to accurately track. If you changed your LAN subnet, or added an interface, the rules would need to change and it would need to know which were yours and which were automatic. The ticket above has a good compromise in functionality.
-
Thanks Jim. Has Alix reset button feature ever been considered or tested to work on pfSense? I wonder if something can be hacked together as a script to trigger a reload and restart of pfsense from a stored config template file.
-
Thanks Jim. Has Alix reset button feature ever been considered or tested to work on pfSense? I wonder if something can be hacked together as a script to trigger a reload and restart of pfsense from a stored config template file.
At a quick look, if you copy some config.xml to /etc/conf.default/config.xml (overwriting the default one) and press the reset button, it should do exactly what you want. (Obviously make a backup before testing :P)
-
The reset button is only probed during boot. If you press and hold the reset button while it's booting, it will reset to factory defaults.
As doktornotor mentioned you can hijack that to replace the default config with your own, but then you could never actually do a true factory reset again (until you do a firmware upgrade and that default config goes back to a stock version)
