James Mackinnon wrote: > As part of my rollout today to Openbsd in my datacenter, I had a > little problem, well not entirely little > > Here is the layout > > 8 TS boxes > > ip config > 192.168.0.20 > 192.168.0.21 > 192.168.0.22 > 192.168.0.23 > 192.168.0.24 > 192.168.0.25 > 192.168.0.26 > 192.168.0.27 > > They have a Load Balance IP of 192.168.0.19 > > All have the same mask and gateway. > > Put in mind, client firewalls not changed and the exact setup worked > fine when my datacenter was behind Checkpoint NG > > I have rules that say > > pass quick log inet proto tcp from <staffsegments> to <TSNLB> port > 3389 keep state > > There is also a rule > pass quick log inet from <TSNLB> to <staffsegments> keep state
FWIW, this rule is likely useless unless the TSs initiate connections to clients. > While on the same segment in my office I can connect to the TS > servers using the load balanced IP but from a branch when try try > they just keep getting the connecting screen in RDP until it times > out. This sounds familiar. > The rules are showing no blocks > > There is no blocking over the VPN for the clients side at all. .All > controls done on the datacenter side Not sure I understand this... > If I bypass the NLB ip on the client side and put in a redirect to so > no client changes are needed, it allows them to connect directly to > one of the ips above rdr on $staff proto tcp from $staffseg to > 192.168.0.19 port 3389 -> 192.168.0.20 ...or this. > Thus, this makes me see it as an issue with the keep state on the NLB > ip, which doesn't make alot of sense since the setup was 100% on > checkpoint > > Has anyone had an issue like this and have any recommendations? While I am NOT a fan of MS's TSNLB, every time I needed this to work properly in Cisco environments, I needed to put a static ARP entry in the routers/firewalls for the NLB MAC/IP--you might want to try giving this a shot. That last time I looked into this issue was years ago so I don't recall the reasonings and associated.
