Openvpn to two lan networks.

pnunn

Hi Guys,

I'm new to pfsense and have hit a wall trying to set up a firewall for my network.

I have two lans (lan=10.90.90.0/8 and opt1=192.168.33.0/24).

I used the openvpn wizard to set up the openvpn server and can get to lan from the vpn connection happily, but having copied the firewall rules for the lan into opt1 I still can't get from outside to anything on the opt1 network other than the firewall itself.

I can ping from vpn->f/w->target as two steps, but not vpn->target (whereas I can on the lan network).

I hope that all makes sense.

What am I missing?

I'm not sure where to grab config files from to add them here, but probably need too I'd guess.

Ta

Peter.

johnpoz

@pnunn said in Openvpn to two lan networks.:

/8

Why would you be using a /8 Does this lan network have some 16 million devices?

Rules on opt interface have nothing to do with getting to the opt network from vpn.

If you can ping the pfsense opt IP from vpn client, but you can not ping device on the opt network then I would suggest you have firewall on opt device blocking you, say windows default firewall setting does not allow ping from other than its local network. And or this device on opt is not using pfsense as it gateway..

On your vpn setup you put in both your local networks - so your client know which networks are on behind the vpn tunnel?

pnunn

Hi johnpoz,

thanks for the reply.

There is no firewall on the server (its a linux box) and I can ping fw->server with no problem (using the command line or diagnostics).

I added the networks to the vpn config and saw in the config that it added push routes that I'd already put in via custom options.

The vpn config is as follows

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 103.168.44.133
tls-server
server 192.168.20.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'MelVPN' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 5
push "route 10.90.90.0 255.0.0.0"
push "route 192.168.33.0 255.255.255.0"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
ca /var/etc/openvpn/server1.ca 
cert /var/etc/openvpn/server1.cert 
key /var/etc/openvpn/server1.key 
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
ncp-ciphers AES-256-GCM:AES-128-GCM
persist-remote-ip
float
topology subnet
push "route 10.0.0.0 255.0.0.0"
push "route 192.168.33.0 255.255.255.0"

The double push's are due to the entries in the config and the optional parameters.

I agree the /8 is crazy big (happens to be what the switch is set too what I will change to a /24 at some point).

What has me tossed is I can ping

client->server via the lan network
client->f/w and f/w->server on the opt1 network.

Could it be route back? Nat?

johnpoz

@pnunn said in Openvpn to two lan networks.:

push "route 10.90.90.0 255.0.0.0"

this statement is gibberish to be honest.. with a mask of 255.0.0.0 the last 3 octets mean nothing..

The double push's are due to the entries in the config and the optional parameters.

Why - pointless 2 do it twice.. What is the client network.. Why don't you look on the clients routes, does it show to get to 192.168.33 it goes down the tunnel? What is its local network.

When you traceroute to something on 192.168.33 does it go down the tunnel? If so then sniff on pfsense opt interface.. Do you see the traffic go out to the box on the 192.168.33 network.. If so then the problem is not on pfsense but the client - it has a firewall? Linux can have host firewall. Does it use a different default gateway than pfsense 192.168.33.X address on is opt interface?

Did you mistake put a gateway on the opt interface on pfsense?

Could it be route back? Nat?

There wouldn't be any nat between lan and opt.. Did you mess with your outbound nat? take it off auto? But sure if your box on your 192.168.33 really has say a /16 mask, it would think that the vpn clients tunnel IP 192.168.20 was local and not send it back to pfsense.

I suggest you sniff on opt interface do you see traffic sent to client, is client actually sending traffic down the tunnel - ie can client get to 192.168.33.x IP of pfsense opt interface. If so then problem is on your box in your 192.168.33 network.

marvosa

I have two lans (lan=10.90.90.0/8 and opt1=192.168.33.0/24).

Looks like you've already been beaten up about the 8-bit mask on your LAN subnet, hopefully, you know that's entirely too wide and have changed it or are at least working towards changing it.

A few things:

I see you're double NAT'd, that's one of the first things I would resolve. It's not a deal breaker, but it's adding unnecessary complexity.
Where are you testing from? Hopefully from outside your network. Also, in a routed solution, there shouldn't be any overlap in the subnets between the local and remote end or it breaks the routing. In other words, make sure the LAN subnet on the remote end where you're testing from doesn't match the subnet you're trying to access.
Your LAN subnet is actually 10.0.0.0/8 (not 10.90.90.0/8) and should be reflected correctly on the IPv4 Remote network(s) line in your config.
You have a split tunnel config, so why are you pushing public DNS to your clients? Is there a reason you want to control what DNS servers your clients are using when they're browsing the internet on their own connection? Personally, I would remove those DNS lines from your config.
You can remove the manual push entries in the advanced section. Both entries are covered in the IPv4 Remote network(s) line and redundant.
Verify the target device is using PFsense as the default gateway. I would also re-verify the mask on the target device to make sure there aren't any typos.
I would change the firewall rules on OPT1 to any/any until basic IP connectivity is established.

pnunn

Hi marvosa,

yes have been beaten up, rightly about the 10.0.0.0/8. I was being lazy and simply hadn't changed the ip on the switch.

I've now set that network up to be 10.90.90.0/25. The other network is 192.168.33.0/24 and my "wan" in 192.168.44.0/24.

I should have said that I'm testing all of this to be used in a data center and so have it all currently set up on the bench with my work lan acting as the wan for this setup. Consequently the servers I'm trying to access have their default gateways pointing to the router on the 192.168.44.0 network on a seperate nic not going through the firewall.

For testing I'm connecting to the 44.0 network and bringing up the openvpn connection to get me onto the router.

For some reason as yet unclear to me, the 192.168.33.0 network is now behaving and I can see the machines on this network (OPT1) happily. I'm still not able to get anything across from the openvpn connection and the 10.90.90.0 network however, despite being able to see everything from everything within the network.

I'm probably over complicating things here and am considering dropping it all to one lan to be honest, but I'd still like to get this going anyway just to prove I can.

You mention double nat? How do you see that? Does what I'm trying to do here make sense or is it just a bad design?

I've set all of the firewall rules on the OPT1 network now stand as any -> opt1 address and opt1 net -> any. The same thing on lan just doesn't work.

Comments? Suggestions? Please.

JKnott

@johnpoz said in Openvpn to two lan networks.:

Why would you be using a /8 Does this lan network have some 16 million devices?

Wait till he gets to IPv6, with 18.4 billion, billion addresses available on a LAN.

johnpoz

Completely different doesn't matter if it was 36 Billion - /64 is the smallest network to use.. with 1000's of possible networks left in a simple /48, 65 some thousand of them... It would be like them setting a /48 on their interface - which also would be WRONG!! The problem isn't really how many possible addresses available in the space... its that they are using up the whole freaking 10 space that can support 1000's of smaller networks.. in 1 network. At that rate they suck up the rfc1918 space in 3 vlans..

Derelict

Yup. IPv6 lets you stop worrying about host addresses because every subnet has 18 billion billion. You worry about networks.

pnunn

OK, why does the default route have to point to the Firewall? This confuses me. I've got the default gateway heading straight to the internet on a different nic to the ones connected to the firewall.

I obviously can't have multiple default gateways. I would have thought that if the routing for the subnet was correctly pointing to the nic on that subnet it should have just passed the traffic back on that nic.

Am I missing something here?

JKnott

@pnunn

The default route is simply the way out of the network. It's just like driving somewhere. The first thing you have to do is get out of your driveway. On more complex networks there may be other, more specific routes that might be used first, but eventually you'll need a default route. The only exception is at the top level, between ISPs, carriers, etc., where every possible route must be known and the packet gets dropped if there isn't a route.

You could route through an interface, but only on point to point links. On Ethernet, there's always the possibility of more than one other NIC out there, so you can't rely on using just the interface.