On Wed, Dec 11, 2013 at 2:32 PM, Joe Landman < [email protected]> wrote:
> Hi folks: > > Trying to figure this one out. Very simple concept, I want to take one > virtual IP (VIP), and tie it to an internal (isolated) machine for > customer/partner use. I've done this before using other firewall > appliances, and it works pretty well for its use case. I just tried to do > the same thing here. > > > External IP: a.b.c.d > Internal IP: e.f.g.h > Internal Machine: i.j.k.l > > I started at Firewall->NAT->1:1 > > Added the rule: > > External subnet IP: a.b.c.d > Internal IP: e.f.g.h > Destination: i.j.k.l > > Made sure I had a VIP setup with a.b.c.d. I've got ping set up for > testing, and it worked nicely. > > Next I tried sshing to that box > > ssh -vvv [email protected] > > Nothing. No negotiation, which usually means it can't reach it. So I > logged into the pfsense box, and did a > > tcpdump -i em5 # the private NIC going to the isolated machine > > at the shell. I did not see the ssh traffic, or the pings. > > Ok, I tried a few other combinations (changed internal IP to destination > IP, and the converse of that). Still nothing. > > So I deleted that rule, and did a simple multi-port forward. All TCP/UDP > showing up for any port 1-65000 on a.b.c.d is port forwarded to the > destination starting at port 1. > > That worked. I see the traffic with tcpdump, I can ssh in, etc. > > But I don't like that, as it seems ... hack-ish. I would think the 1:1 > would be cleaner (and use fewer states?), but I am not sure about this. > > Is there any magic incantation, burn offerings, or typing one can do to > diagnose this? The tcpdump on the internal port on the pfsense box is a > good indicator if packets are getting through. Is there somewhere else to > look on the system to watch the decision processes it makes during the pf > filter pipeline? > > Or should I simply be happy that it works, and not worry about it? I am > happy to file a bug report if it makes sense, I figured I'd ask first to > see if someone thinks this is pilot error (very well could be). > > Thanks! > > > Joe > > -- > > Joseph Landman, Ph.D > Founder and CEO > Scalable Informatics, Inc. > email: [email protected] > web : http://scalableinformatics.com > twtr : @scalableinfo > phone: +1 734 786 8423 x121 > cell : +1 734 612 4615 > > _______________________________________________ > List mailing list > [email protected] > http://lists.pfsense.org/mailman/listinfo/list > Monitor blocked attempts under Status --> System Logs --> Firewall ... filter for the IP you want. If you see the block, click the small grey arrow with a plus sign next to the destination IP. This will create a rule and allow you to go to Firewall --> Rules to indentify the proper rule setup to pass these SSH attempts. Next, notice that these rules are in order...top to bottom. Here is the sentence at the bottom of all firewall rule pages: * Hint: * - Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed). This means that if you use block rules, you'll have to pay attention to the rule order. Everything that isn't explicitly passed is blocked by default. PS: By default, all blocked attempts are logged. After creating a rule, you can also turn on logging for the rules that pass. This will allow you to see the source/destination that is using the rule.
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
