OPNsense Forum
Archive => 20.7 Legacy Series => Topic started by: hpaptech on December 10, 2020, 09:16:35 pm
-
Hello,
I'm switching over to OPNsense for our office firewall and vpn server. While I'm migrating I left the old VPN up. As it's gonna take me a while to get to all the remote locations and reset the endpoint IP. As well was still trying to learn how to set it up.
So I created a route to send that traffic to the old VPN appliance.
https://prnt.sc/w01hq9
I then went into the Firewall -> Rules -> Lan and created a rule to allow all the traffic. Edit: the content of the alias is 172.19.0.0/16
https://prnt.sc/w01k6t
However when a local machine tries to connect or respond to an incoming request from the old VPN it's getting blocked by the default deny rule.
https://prnt.sc/w020in
So i'm not sure why it's getting blocked. Thanks in advance.
-
Not sure I follow what you are trying here. In the end you write response to incomming. Well which rules do you have on WAN interface forward rule in NAT? Because I think that deny rule is the incomming into WAN auto generated rule.
-
Hard to say if you’re not explain what the content of the aliases in the rules.
Sometimes it helps to dump all states or do a reboot if you’re sure your rules should work.
-
Not sure I follow what you are trying here. In the end you write response to incomming. Well which rules do you have on WAN interface forward rule in NAT? Because I think that deny rule is the incomming into WAN auto generated rule.
Does this help a little bit with the currently layout?
https://prnt.sc/w02n8m
I've not been able to figure out the VPN set up for OPNsense just yet and when I do i still need to leave the old vpn in place for a brief bit while i get everything updated.
So the problem is traffic comes in from the old Cisco VPN appliance. But the responses going back to them are getting blocked by OPNsense. Despite I have a routes and rules for the vpn subnet allowing the traffic.
Hard to say if you%u2019re not explain what the content of the aliases in the rules.
Sometimes it helps to dump all states or do a reboot if you%u2019re sure your rules should work.
Sorry the content is 172.19.0.0/16
-
Hmmm...
Well I guess you need to move the firewall rule you created above the allow all rule since I do not think it will get to your rule. But that is not whats stopping you. I will have a look tomorrow morning when my brain is fresh....
-
Hmmm...
Well I guess you need to move the firewall rule you created above the allow all rule since I do not think it will get to your rule. But that is not whats stopping you. I will have a look tomorrow morning when my brain is fresh....
Well I just noticed something that may leave your head scratching a bit more. I factory reset the machine and reset it up just to make sure I didn't do anything bad.
I'm currently remoted into my Home PC (teamviewer) and connected to the old VPN. I ran a traceroute to one of then lan servers while looking at the fire wall log. I was expecting it to fail, but to my surprise the firewall log showed it allowed (the DNS lookup request part showed up at least). The traceroute did complete as I expected.
https://prnt.sc/w034vu
So thinking that some how it started working. I tired to access web interface of that machine through the vpn. But failed to connected and showed in the log. Though when i look at servers logs. I do see the request incoming.
https://prnt.sc/w0371w
Besides the 2 entires being UDP vs TCP. I see the dns query is showing it's self as and OUT direction, but the https request shows an IN direction.
-
Did you turn off the Block Private network on the LAN side if it's using a private network of 172.19.0.0 Interfaces/Lan/ there is a block bogon and block private network option. Not sure if this helps.
Not sure if it's relevant as well but it could be that you need to setup the 172 network in the Virtual IP's so that it knows it's a relevant LAN network.
-
@hpaptech
so actually cisco and lan-clients is in the same subnet? it is asymmetric routing (cisco sends packets directly to 192.168.9 subnet clients). why you need OPN to route this traffic?
why not to just add route to 172.19/16 through 192.168.9.253 on lan hosts?
-
Did you turn off the Block Private network on the LAN side if it's using a private network of 172.19.0.0 Interfaces/Lan/ there is a block bogon and block private network option. Not sure if this helps.
Not sure if it's relevant as well but it could be that you need to setup the 172 network in the Virtual IP's so that it knows it's a relevant LAN network.
The Block Bogon's in the Lan is off, i even turned it off on the WAN. I did not think of adding a 172 address to the machine. I will give that a try.
Edit: Giving it a LAN address on the 172.19 network didn't work. Still being blocked by Default Rule
@hpaptech
so actually cisco and lan-clients is in the same subnet? it is asymmetric routing (cisco sends packets directly to 192.168.9 subnet clients). why you need OPN to route this traffic?
why not to just add route to 172.19.0.0/16 through 192.168.9.253 on lan hosts?
The Cisco Remote clients and remote lans use 172.19.0.0/16 where the main office use 192.168.9.0/24. Where 9.254 is the default gateway of the main office. So they are not on the same subnet. OPN is routing the traffic is because it is kind of silly to go and set manual routes on the all the devices. Especially for something that is only temporary.
-
where the main office use 192.168.9.0/24. Where 9.254 is the default gateway of the main office. So they are not on the same subnet
192.168.9.253 (cisco) is in 192.168.9/24 subnet. so cisco sends traffic from 172.19 to main office hosts directly, not through OPN. so
can try to disable states in your rule (Advanced options -> state type -> none)