Better logging & RPC Traffic
-
Ive exhausted every possibility with windows based diagnostics of my issue.
And now im of the opinion that it is pfsense that is as fault here.Baring in mind that RPC traffic is generally a random port on windows network, is there any way to get pfsense to both display the logs of whats happening and allow the ports across the site link?
As reference, on both PFsenses, theres a rule on the OpenVPN interface that allows traffic from the remote subnet to the local LAN, and a rule on the LAN interface that allows traffic from the local LAN to the remote subnet.
There is also a rule on the openvpn interface on both PF's that blocks broadcast traffic (in theory) from the DCs to 255.255.255.255.Anyone got any ideas?
-
How would I go about ensuring that ALL traffic no matter what protocol, port, etc; is passed over the openvpn site link without being blocked?
With the only thing I'd want blocking would be broadcast traffic and DHCP traffic?As I'm wondering if the random nature of RPC and the ports its using is causing this…
-
If your rules are set to pass any protocol from/to your subnets, then pfSense wouldn't be blocking it, even if the ports are random.
If pfSense is blocking anything, it shows up in the firewall log, assuming it's not hitting your own block rules that don't have 'log' checked.
If you're curious, check the 'log' box on all your rules on the VPN and watch as you try to connect. Odds are, the firewall is passing everything that tries to go over the VPN.
Some other things to check:
- If you have multiple WANs and use policy routing, make sure that VPN traffic has a pass rule above any rule with a gateway set on it.
- Check your network settings on both systems (client and server) to make sure that Windows firewall is off or is at least considering the current network as a private or work network.
- Confirm traffic flow using the states table and packet captures
-
If your rules are set to pass any protocol from/to your subnets, then pfSense wouldn't be blocking it, even if the ports are random.
So unless I've set a block, it wouldn't block any traffic on openvpn?
- Confirm traffic flow using the states table and packet captures
Huh?
So if we go on the logic that as I've set non block rules on either pfsense that nothing over the openvpn link is blocked, what other causes could we be looking at for this issue. As the only consistent fault is that if the computer is at a remote site over the VPN, RPC services won't connect.
Would changing the VPN to something more basic help? -
Can you get any sort of traffic between the two boxes (RDP client and server)?
Generally speaking if there is nothing appearing in logs as blocked but things are still not working I next look for a routing problem. Like, for example, the server sees the incoming requests to open a session but can't respond because, for whatever reason, it doesn't have a route back to the client.
Steve
Edit: Ooops, read RPC as RDP. :-[ General advice still stands.
-
Every other type of traffic flows fine, from smb, to Rdp, ping, etc;
So I'm not sure, with those working, that its a routing issue as data is being passed back.
Its just RPC traffic, in this case the observes fault is with computers at the remote site being able to request certs from the CA. -
Bump.
Any ideas?Thanks.
-
Set all of your rules to log, see what turns up between those two PCs in the logs, pass or block.
Try to get a packet capture of the traffic on both sides, see what portions of the traffic show up on either side, if at all.
-
Set all of your rules to log, see what turns up between those two PCs in the logs, pass or block.
Try to get a packet capture of the traffic on both sides, see what portions of the traffic show up on either side, if at all.
Already done all that.
Its hard to get it to capture RPC traffic as the ports are random each time.
Assuming that the traffic would be seen in the "allow" rule as previously mentioned, i would assume it would show in a log. -
It's not difficult to capture if you filter by IP and not port. No matter what port was being sent, it would still be from the same source IP to the same destination IP.
Yes, if your allow rules all log, and your block rules all log, then any traffic seen by the firewall would be logged (pass or block) - if you never see traffic hit the firewall then it wasn't sent to the firewall.
-
Running a packet capture on the remote Pf on its LAN interface, filtering on the computer im testing from.
The test to see if traffic is going across is a ping to a computer on the main site.
ICMP Packets are showing, now to test other protocols… -
I can see lots of traffic from the test source to the test destination, ranging along a large variety of ports!
I'll do the same test on the primary PF now too…##EDIT##
On the primary PF, i can see the traffic coming in over the OpenVPN interface.Is there a way to show what in the capture is blocked? Or allowed?
The MSDTC test program shows that the test works from Primary server to remote server, but not remote to primary.
-
A packet capture can't know what was passed or blocked, it only shows packets received on the wire.
The firewall log would show passes/blocks provided that you have your firewall rules all set to log (including the default deny rule controlled by the checkbox on the log settings tab)
-
This may help:
http://support.microsoft.com/kb/224196 -
Thanks but ive read that link before, no help.
The following shows that 135 & "random high TCP ports" are used for cert services. Unfortunately im not sure how i'd go about setting them to specific ports.
http://technet.microsoft.com/en-us/library/cc875824.aspxThis:
http://social.technet.microsoft.com/wiki/contents/articles/1559.how-to-configure-a-static-dcom-port-for-ad-cs.aspx
Seems to imply that i can force the ports to certain numbers…i'll try it in a test lab, see if it breaks anything.I suppose at that point if ive got it on a specific port range and that range is allowed both LAN side and OpenVPN side on BOTH PFs, then that's PF out of the equation then isnt it?
-
Yes, it would appear to be the case.
-
As an update:
I THINK ive resolved this….wasnt PfSense causing this at all, it was TMG.
"strict RPC compliance" was on. Turn it off, and thus far, works fine, as well as fixing a few other minor issues which i assume use RPC or DCOM.
Im still testing but it'll be hilarious if a protocol that MS products rely on to work, is "broken" by a MS product too. :p
