@kpa Thanks.

Dude your rules on dmz have ZERO to do with the problem.. You don't need any rules on dmz for lan to talk to dmz.. The return traffic from dmz back to your client starting the conversation with some on dmz would be allowed by the state. Do you have any rules in floating? If not then do a simple sniff on lan - do you see the traffic from your lan host going to your dmz IP your trying to talk to.. Great.. Do same sniff on dmz interface - do you see traffic when you try and talk to dmz? If so then problem on your dmz host. Post back with your sniff results.. I can duplicate this for you in like 2 minutes if you need to see pictures or something..

That is our current plan for the AM, I appreciate the input!

@johnpoz No I haven't done it yet. I'll post the update as soon as I redeploy my pfsense box.

@mic160 said in PFSense packages offline installation?: I have deployee PFSense in internal network as bridge where no internet is available is it possible that i can install packages like Openvpn and Snort on that by uploading packages through webconfigurator?? or by any other way??? Hello, there is no supported way to do this. You may get this done with downloading packages somewhere and install them with pkg on commandline.

only netgate's own ARM devices are compatible. its unlikely the drivers needed for that routerboard are available for freeBSD

https://www.netgate.com/docs/pfsense/vpn/what-are-the-limitations-of-pptp-in-pfsense.html?highlight=pptp it's time to move to a different vpn setup

ttyu0 is the serial console. Do you have your serial console connected anywhere? Maybe if you are connected with a USB serial adapter, when you shutdown the desktop or other PC it's plugged into, it sends a serial break which may make the menu redisplay which would cause that message.

Use another browser, for example a fresh installed Opera ..... and check ^^

Sorry - my fault. I looked for it and could not find it and saw other thread saying, there was none (apparently outdated). Thanks

Lan rules have NOTHING to do with unsolicited traffic TO the server.. Since the server is not creating the connection. Rules are evaluated as the traffic enters an interface from the network the interface is connected too, towards pfsense. If your vpn can talk to everything on this lan network, except this server I would look to as already mentioned firewall on this server.

Those FreeBSD tunables (such as net.inet.tcp.msl) are for connections to the firewall itself (like to a web server) and have nothing to do with state timeouts in pf and connections through the firewall. The pf timeouts are in System > Advanced, Firewall & NAT.

Right. you have to upgrade CE to 2.4.3-p1. I don't think this info has been refreshed on the new forum yet. There are other threads on it. Here are the basics for what you need to do for the PV NICs: Install it, shut it down. Add the NICs you want, then in XenServer: Get the VM's uuid # xe vm-list name-label="pfSense B" | grep "^uuid" | awk '{print $NF}' 43fdd0da-73ca-22c0-97f6-0ac47ae82360 Get the UUIDs for the NICs # xe vif-list vm-uuid="43fdd0da-73ca-22c0-97f6-0ac47ae82360" | grep "^uuid" | awk '{print $NF}' 6c9cb724-705a-0449-2176-505dd332431d a4c4ec8f-de68-eab3-69c7-d5b6c8be7b53 25e0d1b6-6d9a-6480-4612-e5aca876a922 71919d5a-000c-b9b3-31ed-21fa1674ba4e 1bf1eaf3-50fe-4a12-c3fa-1341766cee08 7b50e7fd-d6ec-598d-8dd6-6068d5f2765b Turn off the checksum checking in the NICs. Run this for all of them: # xe vif-param-set uuid=6c9cb724-705a-0449-2176-505dd332431d other-config:ethtool-tx="off" Boot the VM and the traffic in should flow through fine on the PV NICs. The other major caveat is the HV NICs (reX) support altq shaping. The PV NICs (xnX) don't.

Thank you, its done. As you know it pretty much imported everything so had to make the port change and that was it. I’m able to remote in going over a VPN service here locally but pretty sure it should work from an outside network. Thank you again, your help was greatly appreciated!!!!! update: tested from outside network and working perfectly

no clue why it isnt showing up, but be careful for the order mess you'll get into when adding vmx4 https://forum.netgate.com/topic/132933/vmx-nic-ordering-for-pfsense-on-vsphere-5-5

Managed to make this work for some reason i used <shellcmd> instead of <earlyshellcmd>

Assume for the moment that the error message is actually correct. Check all the existing DHCP Lease information to see if that IP address, MAC, or hostname was already assigned. DHCP can hold inactive lease information for a while. Also check Diagnostics->ARP Table, to see if that IP address is already listed to a different MAC address. It's possible that the address was used in a local static assignment already, not involving DHCP. You should do this shortly after trying to assign the static mapping as ARP entries will expire from the cache. Note: if DHCP relaying is involved you'll need to check this on a box attached to the subnet in question, using "arp -a" (works on *nix and Windows). Originally I thought that it could have been you were trying to make permanent the IP address it got dynamically from the DHCP Pool, but that yields a very specific error message to that effect. At least in version 2.4.3.

@johnpoz said in Question re: security and physical access: So changing your username and redoing certs is fine from actual security stance.. Completely agree these are good steps. Prudent and low cost risk mitigation. Appropriate for OP's home network. But do you honestly think that either the postal company or netgate or employee of said companies compromised your stuff? Not the OP's case, but if you deal with "high value" data, that risk has to be considered. However in that case you'd not have returned any non-volatile storage to any vendor to begin with. You eat the costs of those parts when they fail, because it's less expensive than risking your data. But all the tradeoffs in risks and security could fill a book, several actually. If interested, recommend looking at an outline for Security+, CISSP, or similar certification, just to see the topics. Or go find the scripts and videos of the DNSSEC root key signing key "ceremonies". They not only need to be secure, but completely transparent, got to be twice as stressful. Can't see them shipping those laptops out for repair.