Concentrator or something else?

lewis

I decided to use this as a reference since a split tunnel is in fact the configuration I'd like.
https://www.wundertech.net/how-to-set-up-openvpn-on-pfsense/

It works, I can connect and ping (in this case) the vpn tunnel IP of 10.10.10.1.

The PC I'm connecting from is on a LAN that has networks 192.168.1.0/24, 192.168.254.0/24, and 10,0.0.0/24.
When the vpn is disconnected, I can ping all three gateways but when the vpn is connected, I can ping two but not the 10.0.0.0/24.

The thing is that the LAN network on the vpn server side is 10.0.0.0/24 and the vpn user will need access to those from the vpn connection.

I suppose I have to set up some rules on pfsense now to provide access to some of those servers/services on the the lan.
It's a bit unclear yet how I do that. For example, say I want to give ssh access to 10.0.0.9 on the vpn server side. I'd have to add a rule that would give either everyone or a specific user/ip access to 10.0.0.9. Would the remote user connect to 10.0.0.9 or 10.10.10,1, port 22. If that's the same, it means I'd have to use custom ports for everything.

Maybe I should be using a 172.16.x.x/24 instead for the vpn server, just to prevent some confusion.
I'm also assigning specific IPs to each user so I know who is who.

Lots to learn, another new thing for me.

JKnott

@lewis said in Concentrator or something else?:

So the word 'concentrator' isn't really what this would be but pretty much a vpn server then.

A "concentrator" is simply a means for multiple devices to share a connection, assuming those devices only use it part time. I first came across the term about 50 years ago, when I was a technician working in the Toronto Stock Exchange. Concentrators were used to connect multiple stock broker terminals to a single port on a computer. These days an Ethernet switch could be called a concentrator, when connecting a local network to an ISP. Another name for it is "statistical multiplexer".

lewis

I've hit a roadblock.

I added a rule to allow a specific user/IP to reach a server on the 10.0.0.0 network.

I allowed the IP on the server itself for ssh. I can see the remote vpn user hitting the server but not getting a response.

The firewalld rule;
        rule family="ipv4" source address="10.10.10.10/32" port port="22" protocol="tcp" accept

# tcpdump -i ens18 src host 10.10.10.10
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes
12:20:03.468302 IP 10.10.10.10.50526 > dev09.loc.ssh: Flags [S], seq 1895313320, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
12:20:06.465188 IP 10.10.10.10.50526 > dev09.loc.ssh: Flags [S], seq 1895313320, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
12:20:12.469257 IP 10.10.10.10.50526 > dev09.loc.ssh: Flags [S], seq 1895313320, win 8192, options [mss 1358,nop,nop,sackOK], length 0

Since other hosts can make it to the server's ssh, I'm not sure why this is not working.

johnpoz

@lewis said in Concentrator or something else?:

Since other hosts can make it to the server's ssh, I'm not sure why this is not working.

You have an any rule there at the bottom so yeah anyone would be able to go anywhere.. And rule that allows 10.10.10/24 to go anywhere as well

If you don't want them to get to ssh but only that .10 address, then create below your allow to ssh that specifically blocks to ssh.. or blocks all, etc.

lewis

@johnpoz

Yes, I noticed that I have an extra/wrong rule but wasn't yet sure what to do so left it there.

Do you mean like this?

Since this still doesn't work, I guess I have to review rules I've made in the past on a multi network pfsense that allows traffic between nets.

johnpoz

@lewis that rule would allow specific only - nothing else would be allowed.. So for example if your trying to look up where you want to ssh via dns - dns wouldn't work.

But that rule would allow that source IP to talk to that destination IP on 22 only.

Keep in mind just turning off a rule wouldn't actually block anything that already had a state.

lewis

Yes, that's what I'm after, a rules based access to specific resources.
This first user should have access to certain hosts and ports only.
The split network aspect is perfect for this setup.

Now, I'm still not sure why this rule is not working then. It's forwarding to the 10.0.0.9 server and I see the incoming connection but is never completes.

johnpoz

@lewis Well does this 10.0.0.9 box know how to get back to this 10.10.10 network, its gateway is pfsense?

Does this 10.0.0.9 box have its own firewall?

lewis

It does. I shared it a few comments ago.

The firewalld rule;
rule family="ipv4" source address="10.10.10.10/32" port port="22" protocol="tcp" accept

I can see the remote hitting the server but oddly, it's not allowing it. Strange.

14:33:54.341956 IP 10.10.10.10.60188 > dev09.loc.ssh: Flags [S], seq 2394177693, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
14:33:57.348343 IP 10.10.10.10.60188 > dev09.loc.ssh: Flags [S], seq 2394177693, win 8192, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
14:34:03.359242 IP 10.10.10.10.60188 > dev09.loc.ssh: Flags [S], seq 2394177693, win 8192, options [mss 1358,nop,nop,sackOK], length 0

johnpoz

@lewis so your firewall rule is wrong on the host.. Or its not listening on 22? Or maybe its sending it answer elsewhere?

Just because you see traffic via a sniff, doesn't mean the firewall actually allows it up the stack..

lewis

I understand but It's pretty weird to me that the firewall is allowing everything but this host.
I shared the rule output above. It's like all the other ones.
I think I know why this isn't working. It's because the firewall I set this up on is not on the same network as the server is. Meaning, the servers gateway is different so it's not routing back to this firewall. I'll just move this config to the other one and it should be fine.

At this point, it's not a pfsense issue so I think the post is done :).

lewis

I confirm. Everything is working now. The packets were going back to the wrong gw.
It's too bad the dashboard widget doesn't provide more information about the individual connections but I guess I can get that from some other program on the firewall like bandwidthd for example.

Update: Nope, can't get that from bandwidthd.

All good now.