Better logging & RPC Traffic
-
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
