Thanks johnpoz and doktornotor your completely right. Its better though VPN i guess i got used to ddwrt for a while didn't want to let it go.  :P Just trying to adapt more to pfSense now  :) Thank you again

Please don't hijack threads for unrelated problems. If you have an issue, start a new thread or if you already have, keep the discussion there.

Hi, same problem as you. Did you find a way? Thanks,

This thread has already been over so lets say I have 3 cams cam1.dyndns.tld:8081 cam2.dyndns.tld:8082 cam3.dyndns.tld:8083 now cam1,2 and 3 all point to your public IP lets call it 4.5.6.7, and your cameras on the inside are 192.168.1.101,102 and .103 Are your cameras listening on 8081 and 8082 and 8083 or do you forward to say 80??  Really should forward to the ports your actually listening on. if cams listen on those ports your urls still work just fine be it outside or inside your network. Also having your cameras open to the public net is not a good idea to be honest.  Why don't you just vpn in and use the private IPs directly.  This makes it simple and more secure..  Nat reflection is to be honest never a good idea ;)

@cmb: Do you see a filter reload logged in the system log? Check /tmp/rules.debug, do you see the updated rules there? What happens if you run 'pfctl -f /tmp/rules.debug'? Sure enough, it spit out an error of an alias url file containing rubbish on one line. This was in the locally kept version, I had already spotted the rubbish in the original source file earlier on, but as it never got as far as downloading a new copy, it never replaced the file held in the /var/db/something . Edited the local copy and it loaded normally after that. I will see if it also saves and executes changes in the firewall, but I am sure it will, as this error block all further loading. Thanks.

sounds more like a ssl based vpn to me..  That yes the ASA support, this has nothing to do with routing or forwarding.  And no pfsense does not support that.

Sorry to say it at this late stage, but this really illustrates the importance of taking a regular backup of your running config. Especially before making any changes.

The problem in ISP, thank you for suggestion.

Ok, i managed thanks to this article to have it work https://forum.pfsense.org/index.php?topic=82732.msg453269#msg453269 I did miss the openvpn server service restart I recap, hoping tohelp anyone else: A) VPN tunnel (open VPN) up and Running (see on eof the tutorials) B) BOX B (target side)     1)  Interfaces, Add …. as in the article     2)  RESTART the SERVICE     3)  Remove any rules from the Firweall > OpenVPN     4) Add a rule on OVPNC1 (the virtual adapter) with destination 192.168.99.1 (the internal IP) and the ports (if any specific) C) BOX A (source side)     1) Add a 1-1 NAT with IP_PUB_A <ip1>as public IP and 192.168.99.1 as the target     2) Add a fireall rule (WAN) with target 192.168.99.1 to allow traffic     3) In the OPenVPN tab add an allow all rule et voila</ip1>

Yeah don't understand this sort of setup either, its always best to put the vpn connection at the actual edge, not forwarded to some box inside behind a nat. But to answer your question directly, just forward ESP which protocol 50.  Don't you want 51 as well AH? [image: protocol50.png] [image: protocol50.png_thumb]

You might want to look at the reverse proxy package like HA.

Hi, the best solution would be to set your router in bridge mode and let pfSense do the VPN termination. So the firewall can control all connections from outside itself. I've neither a L2TP set up nor a double natting. So I am not able to share some experience with that. However, if you want to solve it this way let us research… Two elementary things will be necessary to get it work: The VPN clients must know the route to the LAN network. The firewall must allow this access. For allowing access, you have to set up a firewall rule. I assume, your pfSense WAN net is a /24 and the VPN pool uses the same whole subnet. It will be a good advice to reduce the VPN pool to a e.g. /27 or whatever you need, or just more better, to use a different subnet. So it will be easier to distinguish the VPN and internet traffic. So you will have to add a rule to WAN interface to allow access from VPN subnet to your LAN network. If VPN pool uses whole WAN subnet you have to add additional block rules with higher prio to prevent access from internet (192.168.91.254 in your case) and possibly other hosts on this subnet. The other thing is the route at VPN client to the LAN behind pfSense. If your client sets the VPN server as default gateway at establishing connection there should be no additional route required. Otherwise you have to set manually a route to LAN subnet using the pfSenses WAN IP. As far as I know L2TP has no capability to push special routes from server side.

I just created an identical pfSense on VirtualBox and cloned the config on it. Everything works fine. Here's the ifconfig of KVM setup: ifconfig br0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet 192.168.7.2  netmask 255.255.255.0  broadcast 192.168.7.255         inet6 fe80::4ccb:a9ff:feb7:5617  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 0  (Ethernet)         RX packets 2825  bytes 330247 (322.5 KiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 3339  bytes 802554 (783.7 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 enp2s0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::5ea1:75a3:7d46:befd  prefixlen 64  scopeid 0x20         ether 00:90:27:77:fb:02  txqueuelen 1000  (Ethernet)         RX packets 223027  bytes 20719723 (19.7 MiB)         RX errors 0  dropped 178  overruns 0  frame 0         TX packets 6747  bytes 2101069 (2.0 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 lo: flags=73<up,loopback,running>  mtu 65536         inet 127.0.0.1  netmask 255.0.0.0         inet6 ::1  prefixlen 128  scopeid 0x10 <host>loop  txqueuelen 0  (Local Loopback)         RX packets 12388  bytes 1341938 (1.2 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 12388  bytes 1341938 (1.2 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 macvtap0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::26f4:1e55:97a0:c0cb  prefixlen 64  scopeid 0x20         ether 00:90:27:77:fb:02  txqueuelen 500  (Ethernet)         RX packets 217268  bytes 20328935 (19.3 MiB)         RX errors 8919  dropped 8919  overruns 0  frame 0         TX packets 6620  bytes 2073711 (1.9 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 vnet0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::5d6b:398c:6b44:d602  prefixlen 64  scopeid 0x20         ether fe:54:00:6f:2e:15  txqueuelen 500  (Ethernet)         RX packets 4558  bytes 4062075 (3.8 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 4583  bytes 624983 (610.3 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 wlp1s0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::6e57:fe92:1321:1521  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 1000  (Ethernet)         RX packets 6040  bytes 811010 (792.0 KiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 7038  bytes 4986969 (4.7 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0</up,broadcast,running,multicast></up,broadcast,running,multicast></up,broadcast,running,multicast></host></up,loopback,running></up,broadcast,running,multicast></up,broadcast,running,multicast> and of a much cleaner, and - more importantly - working VirtualBox setup: # ifconfig br0: flags=4163<up,broadcast,running,multicast>mtu 1500         inet 192.168.7.2  netmask 255.255.255.0  broadcast 192.168.7.255         inet6 fe80::a288:69ff:fe0d:5c41  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 0  (Ethernet)         RX packets 4999  bytes 1686341 (1.6 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 9269  bytes 2203282 (2.1 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 enp2s0: flags=4163<up,broadcast,running,multicast>mtu 1500         inet 192.168.11.13  netmask 255.255.255.0  broadcast 192.168.11.255         inet6 fe80::201:2eff:fe4e:4b99  prefixlen 64  scopeid 0x20         ether 00:01:2e:4e:4b:99  txqueuelen 1000  (Ethernet)         RX packets 175668  bytes 58689989 (55.9 MiB)         RX errors 0  dropped 35  overruns 0  frame 0         TX packets 33594  bytes 2862399 (2.7 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 lo: flags=73<up,loopback,running>mtu 65536         inet 127.0.0.1  netmask 255.0.0.0         inet6 ::1  prefixlen 128  scopeid 0x10 <host>loop  txqueuelen 0  (Local Loopback)         RX packets 44600  bytes 11957420 (11.4 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 44600  bytes 11957420 (11.4 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 wlp1s0: flags=4163<up,broadcast,running,multicast>mtu 1500         inet6 fe80::a288:69ff:fe0d:5c41  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 1000  (Ethernet)         RX packets 4400  bytes 1698452 (1.6 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 8264  bytes 2315002 (2.2 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0</up,broadcast,running,multicast></host></up,loopback,running></up,broadcast,running,multicast></up,broadcast,running,multicast> So it looks like KVM is not suitable for hosting pfSense VM if host machine is required have access to the internet. It is a shame as I was hoping for KVM to be not just working, but a superior solution. Can someone move this thread to Virtualization?

After some more testing it seems the NIC was somehow damaged during the hardware upgrade. Even though it worked fine in the old machine, by the time it was in the new one it had broken. Replacing the NIC with a new one has completely resolved the issue and link speed does not need to be set manually anymore either. Thanks for your thoughts and support! It is greatly appreciated.

agreed, or pointed to this article. https://doc.pfsense.org/index.php/FTP_without_a_Proxy

No, this thing is NOT managed via shell. Backup the configuration, read the config.xml and have fun with mass adding there. Reimport when done.

@Bigzaj: I'm trying to do something similar with a DDNS service.  I have one domain I want to redirect to multiple internal IP based on port. You already have your own thread.

The server's sending the SYN ACK in response, the question is why doesn't it get to the client. Does it leave WAN? @Derelict: I thought NAT took precedence over services listening on the firewall. It does, that's not relevant here.

Port forwards rewrite the destination. Outbound NAT rewrites the source. Disable outbound NAT if you don't want it to NAT, or set it to hybrid or manual mode and configure your rules accordingly if you don't want all NAT disabled.