How do I allow VNC from one subnet to another?
Thanks! I set up a VM on the server directly on the 1.x segment, and it turned out that I could both sniff and get to the 10.x segment from that. So it seems the problem is in my server, which is kind of logical when I think about it. The Windows Server 2016 needs to know that requests to 10.x should go through the 1.x network. I tried setting up a static route in Routing and remote access on the server, but that didn't work, so I have to experiment a bit more to find out how I can route that.
So you have multihomed server, ie it have interfaces in more than 1 network? Why would it go through your 1 network if its on the 10 network already??
Why don't you draw up how you have this server actually connected... Multihoming a server is normally BAD IDEA!!!!
The server does not have (shared/NAT-ed/routed) interfaces in more than one network. The pc I want to connect from is on the server's internal network, 192.168.0.x, the server uses the 1.x segment from the pfSense box as it's WAN, and then I wanted to go like this:
Pc on 192.168.0.50 --> Server internal NIC 192.168.0.1 --> Server WAN 192.168.1.4 --> pfSense egetnett (the server's wan) 192.168.1.1 --> pfSense Airplay 192.168.10.x
If your server is a downstream router... Then its wan this 192.168.1 network becomes a transit.. There should be NO hosts on this network.. It is a transit network between routers.. If your going to put hosts on it.. Then this server (router) would need to nat traffic from the 192.168.0 to 192.168.1.x (its wan address).. If you expect the 192.168.10 to know how to get back to it..
If you do not nat, then pfsense needs to know to get to the 192.168.0 network to talk to this servers (downstream router) IP on the 192.168.1 network.
The server sees the .1 network as a pure WAN, yeah. The server has no outgoing DNS, DHCP or anything else to that net, everything there is controlled by the pfSense box.
But I'm afraid I need it dumbed a bit down, sorry... Do you mean that I need to put some kind of a static route from the 10.x network to the 0.x network with the server's external IP as the gateway? I thought the 10.x network would see the contact coming from the server's external IP on the 1.x network (192.1681.4), and that the rest had to be done in the server.
If your server nats the 192.168.0 netework to to its WAN ip 192.168.1.x then you have not problems. If it is NOT natting this and pfsense is seeing a source IP of 192.168.0 on its egetnett interface then for starters you need to allow for that.. Since 192.168.0 is NOT egetnett network 192.168.1
And pfsense also needs to know how to get to 192.168.0 via a route and a gateway..
where did you sniff this
14 1.776350 192.168.0.50 192.168.10.102 TCP 66 52111
If you sniffed that on pfsense then your server is NOT natting to its 192.168.1 address.
And its not a static route from the 10 network.. Its route on PFSENSE saying hey to get to 192.168.0 talk to 192.168.1.x
So you need a gateway setup. And you need to create the route... And then you will need to enable the rules on egetnett to allow for 192.168.0
And if you want 192.168.0 to get to the internet you would have to make sure that pfsense does outbound natting of this 192.168.0 network
For the life of me have no idea why you would do it this way... Why not just directly connect 192.168.0 to pfsense - what is the point of this server doing routing downstream of pfsense?
So you have other devices on this egetnett? If so them talking to stuff on the 192.168.0 is going to be asymmetrical..
I understand. I see that nothing happens in the Firewwall log when I try to VNC out, and there's no mentioning anywhere in the firewall logs about a 0.x segment, only 192.168.1.4 (the server's external network) so that should mean that the server should NAT to the WAN.
The sniffing was done on the internal network, on the same 0.50 pc that's trying to get to the VNC's on the 10.x network.
And 0.x has always gotten to the Internet, that's a problem. It's just getting from the internal network via the Server and to the 10.x segment that doesn't work. Which led me to think that I needed a static route to the 10 network. pfSense sees "hey, 192.168.1.4 on the Egetnett wants to talk to somebody on the .10 net, so I'll route it". And it can. So I think this is a matter of finding out how the Server can be aware that it needs to go to the pfSense on 192.168.1.1 to get to the 10.x network. I guess that's what you're saing in the bottom added part, right?
Sniff on pfsense egetnett interface for 5900 tcp... Try and get to your 192.168.10 address from your 192.168.0 address.
Do you see traffic?? What is the source IP?
Now sniff on the airplay interface for tcp 5900 and try and get there again... Do you see pfsense send on the traffic???
"hey, 192.168.1.4 on the Egetnett wants to talk to somebody on the .10 net, so I'll route it".
Pfsense KNOWS how to route to any network connected to it... You do not have to create any routes... You have to allow it via a firewall rule on egetnett interface.
You say that 192.168.0 can get to the internet... So how is the default gateway of this server your 192.168.0 behind NOT pfsense IP address in the 192.168.1 network?? If its NOT then NO its never going to get to the 10.. Does this server your 192.168.0 have some other default gateway.. Does it have some other connection to the internet that you say the 192.168.0 can get to?
This is your network???
I need to set up something that can sniff on that network. I'll try to do that tomorrow and see if I can find out something.
The default gateway to Internet in my internal network is the server , 192.168.0.1, and the default gateway for Window's Routing and remote access (and NAT) on the server is 192.168.1.1, which is the pfSense box. And the 0 segment has no other way to the internet than Server --> pfSense --> ISP Internet router
Sniff on pfsense egetnett when you try and got vnc on the 192.168.10 address... If pfsense does not SEE this then no you can never get there.. Maybe your server is blocking it from going out?
This is really 30 seconds to figure out with simple packet capture on pfsense to validate traffic gets there and is sent on..
Sorry, I answered before you put in that network pic. Yeah, that's basically my network, at least the part of it that I am trying to get to work now.
I hadn't seen the package capture function on pfSense before, but I tried it now. I did packet capture on the Egetnett and nothing was shown that tried to go from 0.50 to the 10.x segment. Then I tried a VM that's connected directly to the 1.x segment (physically on the server, but totally separate from the 0.x network), and there I could see the packages going back and forth.
So it seems obvious that the server has no idea where to send stuff to 10.x segment, I need to figure out how to tell it that.
from 0.50 to the 10.x segment.
OMG dude... No shit you would not see traffic from 0.x your server is NATTING the traffic to 192.168.1.4 - how else could stuff on the 0 get to the internet... Pfsense has NO clue to the 192.168.0 network..
Your server has only its default gateway right 192.168.1.1 (pfsense) so it sends ALL traffic there that is not local.. Do you maybe have this 192.168.0 with a /16 mask or something??
No, it's a 24 mask. But I meant that I don't see any VNC traffic AT ALL when when trying to get from 0.50 to the 10.x segment. So there's no VNC traffic coming out of 1.4 either.
Well then you need to figure that out on your downstream server - pfsense can not let you into the 10 network on port 5900 if it never gets there.
Seems pretty impossible if your default gateway is pfsense, unless your server is blocking traffic to rfc1918 space.. Can your 192.168.0.50 box ping say 192.168.1.1?
You would have to allow that on your egenett rules.. I don't recall what they were now..
From the rules you listed - sorry but its not possible for those 192.168.0 boxes to be getting internet through pfsense.. Since rules on that interface only allow access to the egetnet address.. So unless you were using proxy?? On pfsense?
Unless you have rules below what you posted for 5900 dest..
Yeah, I know. It has to be lost somewhere on the server, I guess that's because it doesn't know where to send requests to the 10.x subnet. I tried to set up static routes to do that, but it didn't do anything.
And yes, I can ping both the pfSense box and the VM that's running on the Egetnett. So the server should not block 1918. I am not using proxy. And yes, I have other rules, I just cut out the rule for the 5900. Default LAN to any rule should cover that, right? Also now for testing I have a rule on Egetnett allowing anything to Airplay net.
FOUND IT! It was the server, and I saw it when I used route print. An old, static route from an experiment several weeks ago was overriding the new static route I had set up. I deleted the old route, and now it works. Thanks for you help!
Edit: The weird thing is that the old route was taking presedence over the new route, which I had with metric 1. I have no idea why.
9 days ago in #2 I told you about Asymmetric/check your Routing.
Rico, turned out that it wasn't that at all. The routing I thought was wrong was only for internal use on the server, I didn't check the RAS routing table, which was correct. So something strange happened in the pc. But now I'm back with the problem, only different. After fiddling with the rules for both airplay and egetnett I see what seems to be happening. I see the VNC packages on the Airplay net, but they are blocked. Because I get this:
Dec 9 20:43:58 AIRPLAY Default deny rule IPv4 (1000000103) 192.168.10.101:5900 192.168.0.50:50613 TCP:SA
Now that confuses the heck out of me, because I keep getting that even with this rule on the very top of Airplay:
Shouldn't that rule let everything through? Also I can't understand why I'm seeing the internal IP of the client, and not the 192.168.1.4 IP of the server, but perhaps that's the way it is so that the server can send it on to the correct client?
SA screams of Asymmetrical traffic!!!
Shouldn't that rule let everything through?
NOT when it is not SYN... You do NOT need rules on airplay to allow return traffic that is started from egetnett... The state will allow the return traffic...
Like I said draw up your network.. If your seeing SA.. Means you are asymmetrical.. Ie send the Syn,ACK back to firewall where the SYN came from some other path that the firewall did not SEE.
I will try. What is the software/website you're using to make your drawings? It seems quick and easy compared to the stuff I've tried.
I use visio.. But there are plenty of places to do online drawing..
Here is ascii art one that is pretty slick
there is giffy
Here is the thing if your multihoming shit - then you going to have issues with asymmetrical traffic unless you KNOW what your doing.. Its real simple to not have asymmetrical traffic... ONLY put stuff on 1 network, and any upstream/downstream routers would be connected with transit networks
Thanks for the drawing tips! But it seems like I don't need them this time. I really don't get this. The 10.4 NIC is still nowhere in the RRAS routing table, but I can see that it is assymetrical traffic. So for now I have given up on using the clients for VNC and instead VNC into the server and then from that to the 10.x devices. At least that way I will keep the bulletproff failsafe in the totally static 10.x network for my automation. I am going to find out how to avoid this in a Windows Server forum. Thanks for the patience, I'll put on my flame retardant raincoat and you now get to say "I told you so".
If your 192.168.1 is only transit, and your server has connection to it and its .0 network behind it.. And this .0 network is not connected to anything else then its not possible for you to have asymmetrical traffic.
How would traffic get to the 10 devices other then via pfsense connection?
Do you have multiple layer 3 over the same layer 2 network? Ie do you have devices with different IPs plugged into the same dumb switch? And thinking they are on different networks?
That's the confusing thing. The only assymetric way I should be able to get from the clients on the 0 network would be through the going like this:
Client...................RRAS server NIC...........Server NIC excluded from RAS
192.168.0.50 -- -> 192.168.0.1 --------------> 192.168.10.4 -------------------> 192.168.10.x
And that's what I don't understand. I think I'll have to get down to the technical room and go over the connections. I recently moved the server from one rack to another (I needed more space for the whole house audio amps, they got HOT because they were to close together, so I split the system over two racks) and it is possible that there is a wrongly plugged cable connecting the 1.x and the 10.x network, or perhaps even the 0.x and the 10.x network. That's the only think I can imagine. That would be a lot of hours wasted on a network cable...
Your server is multihomed - it has a connection in the 10.. As I stated doing such a thing leads to problems - especially if you do not fully understand how the protocol works and will not be coming to a device on the 10 from another direction.
You do understand that if its directly connected then there is a ROUTE!!!!
You hit the server and tell the server hey, send this to 192.168.10.X
Server - sure directly connected to that network, and hey I arp for X and its here on this network... Let me throw that SYN out to it for you..
10.X sees that SYN from 192.168.0.50... Say hey yeah I listen on that 5900 port, let me move that traffic up the stack for you hey... Hey it says yeah lets talk,, he sent me this syn,ack he wants me to send back to you.. Oh lets see 192.168.0.50... hmmm I don't know how to get there.. Let me send that to my friendly default gateway pfsense at 192.168.10.1 - he will know how to get it to the 0 network..
Pfsense - says sees the SA... Sorry bud NO state.. Dropped!!!
I do know that. And I too think that's what happening. The thing is that what's a route locally on the server and what's a route on Routing and Remote Access, dealt out to the clients of the server, at least in theory should be two different things. That's why there are totally different route tables for RRAS and Route print on a server. So the clients shouldn't even be able to go through the 10.4 NIC as long as that's blocked in RRAS.
But I will check the cabling, and I'll see if I can find out if RRAS routes and local server routes are to be totally separate, and that it may be a configuration mistake on my server. I have put in a question about that on a server forum. This is something new for me, even after almost 20 years of running "indows server (from 2000 Advanced Server) at my home and my cabin.
Dude we stopped using RRAS like 20 some years ago... I have supported "server" since NT 3.51 days... Got my MCSE back on NT 4 and 2k..
There are much easier ways to route traffic then using windows that is for damn sure.. For starters your using one - pfsense..
Not sure what you think putting device behind windows is getting you other then more complexity?
Somebody forgot to tell Micro$ft and some tens of milliones customers about that... My server is a combination of RRAS, DHCP, DNS, VM host, storage host, media host, media server and several special programs for work and automation that can't run on anything but a physical Windows computer. If I didn't do it this way, I'd have to use at least three boxes.
Sorry I have been supporting 100's if not 1000's of customers over the years.. NOBODY still uses RRAS but the smallest of smallest SMBs -- sorry nobody uses it in real networking ;)
All of those services for sure can run on your windows Box.. Just that there is ZERO use for it to be doing RRAS..
I know you are as superior in this as I probably am to you (and to Google Translate!) in English to Norwegian translations (which is my job). But this small SMB still use it. Of course there's a lot of the old "since I have been using this with almost no problems for 20 years, there's no need to start learning something completely different". Also I have been running M0n0wall before pfSense since forever, so I have never been hacked either.
This stuff is the first real problem I've had for as long as I can remember, so it has been very low maintainance for me. So I figure it's worth seeing if I can find out anything on the server forum. If not I can probably live with using VNC indirectly.
If not I can probably live with using VNC indirectly.
That is just moronic to be honest.. Fix your ASYMMETRICAL routing... Why is this server even multi homed?
As I said before in another thread, where I managed to get fixed the then problem (slow to stopping file transfers), to isolate Airplay and automation devices completely from the 0 network while keeping them directly connected to the server for 100 % stable access no matter what goes down, as long as it isn't the server itself (which honestly doesn't happen with Windows Servers without a serious hardware problem since Windows Server 2003 R2 in 2005). And the Airplay devices can't be isolated from the client network if I use the addon to send Airplay from the 192.168.1.x segment to the 10.x segment. As for moronic, probably. But as long as it doesn't give me practical problems, I'm good with it. Just like my Honda Blackbird still does 200+ mph and 0-60 in less than 2.5 seconds even if there are a few scratches on it.
So your multihoming incase your ROUTER goes down pfsense?? So your issues is 110% self inflicted nonsense then... If your that worried about router going down.
I take it all your switches that connect everything are dual with multiple power supplies and every client has 2 connections?
If your worried about your router/firewall going down then run it HA...
As I said that's half of it, the other half is the Airplay thing. probably more than haf, 2/3 isolation and 1/3 safeguard.
The PI clients have both wifi and wired connection, yes. And no, it isn't just the router, there are some dumb switches that do not have a UPS setup (my server and main setup has a dual car battery setup for 8 hour UPS) that connects the Pis to the main technical room. And they are spread out because this house has some brick walls that blocks 433 mHz signals.
You bring up security and then you multihome a server - which bypasses all firewalls and is HUGE SECURITY issue!!!
Oh, not at all! The 10.x segment I'm multihoming is coming directly FROM the pfSense firewall, and it's blocked for the Internet except for one port, SMTP (sending warning mails if someting stalls). The only possible vector is the wifi, and that has a very long passphrase in Norwegian that isn't possible to do wit brute force for a few million years. So yeah, there is the WPA-2 vulnerability, but they would have to be very close to the house to access, and my mastiff would probably start barking then.