Pfsense or Proxmox issue?

Please help. I’m not sure if I’m experiencing issues with pfsense or proxmox. I have a proxmox pve server running on LAB VLAN 192.168.69.0/24.

My main computer is on a HOMELAN VLAN 192.168.40.0/24.

If I try to upload an ISO image to my proxmox server, it only xfers 32K of the file before coming to a complete stop.

However, if I am on the same VLAN that my proxmox server is on, I’m able to xfer files to the server with no problems at all.

Here’s my firewall rules for both LAB & HOMELAN VLANs:
LAB VLAN:

HOMELAN VLAN:

Am I overlooking something here? I’m not the best at networking, so I’m not sure if this is a pfsense or proxmox issue. Please help!

Thanks!

It doesn’t look like the firewall rules are causing the issue. How exactly do you try to transfer the file? Via the Upload button in the Proxmox webUI?

The second rule “allow any to LAB net” is not needed, because traffic within the same subnet never hits the firewall, so anything in the LAB subnet can talk to anything else in the LAB subnet anyways. And even if this rule were necessary, which it is not, it would have to be placed above the “allow any to !RFC1918” rule in order to have any effect.

I have tried uploading from both the webui and through scp.

Results of me trying through scp:

scp -v /home/fleabeard/Downloads/elementaryos-6.1-stable.20211218-rc.iso root@192.168.69.2:/tmp
Executing: program /usr/bin/ssh host 192.168.69.2, user root, command scp -v -t /tmp
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.69.2 [192.168.69.2] port 22.
debug1: Connection established.
debug1: identity file /home/fleabeard/.ssh/id_rsa type 0
debug1: identity file /home/fleabeard/.ssh/id_rsa-cert type -1
debug1: identity file /home/fleabeard/.ssh/id_ecdsa type -1
debug1: identity file /home/fleabeard/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/fleabeard/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/fleabeard/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/fleabeard/.ssh/id_ed25519 type -1
debug1: identity file /home/fleabeard/.ssh/id_ed25519-cert type -1
debug1: identity file /home/fleabeard/.ssh/id_ed25519_sk type -1
debug1: identity file /home/fleabeard/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/fleabeard/.ssh/id_xmss type -1
debug1: identity file /home/fleabeard/.ssh/id_xmss-cert type -1
debug1: identity file /home/fleabeard/.ssh/id_dsa type -1
debug1: identity file /home/fleabeard/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5+deb11u1
debug1: compat_banner: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.69.2:22 as 'root'
debug1: load_hostkeys: fopen /home/fleabeard/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:d7/c71x9GeugN9jfTYVlKSob4K2qCyAarmyCwJp22sY
debug1: load_hostkeys: fopen /home/fleabeard/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.69.2' is known and matches the ED25519 host key.
debug1: Found key in /home/fleabeard/.ssh/known_hosts:7
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /home/fleabeard/.ssh/id_rsa RSA SHA256:qXCS673vALAn+0IuRybbf16H741/NgfcpeLjVFwUalE agent
debug1: Will attempt key: /home/fleabeard/.ssh/id_ecdsa
debug1: Will attempt key: /home/fleabeard/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/fleabeard/.ssh/id_ed25519
debug1: Will attempt key: /home/fleabeard/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/fleabeard/.ssh/id_xmss
debug1: Will attempt key: /home/fleabeard/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/fleabeard/.ssh/id_rsa RSA SHA256:qXCS673vALAn+0IuRybbf16H741/NgfcpeLjVFwUalE agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/fleabeard/.ssh/id_ecdsa
debug1: Trying private key: /home/fleabeard/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/fleabeard/.ssh/id_ed25519
debug1: Trying private key: /home/fleabeard/.ssh/id_ed25519_sk
debug1: Trying private key: /home/fleabeard/.ssh/id_xmss
debug1: Trying private key: /home/fleabeard/.ssh/id_dsa
debug1: Next authentication method: password
root@192.168.69.2's password:
Authenticated to 192.168.69.2 ([192.168.69.2]:22) using "password".
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching /home/fleabeard/.ssh/known_hosts for 192.168.69.2 / (none)
debug1: client_input_hostkeys: searching /home/fleabeard/.ssh/known_hosts2 for 192.168.69.2 / (none)
debug1: client_input_hostkeys: hostkeys file /home/fleabeard/.ssh/known_hosts2 does not exist
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: Sending command: scp -v -t /tmp
debug1: client_global_hostkeys_private_confirm: server used untrusted RSA signature algorithm ssh-rsa for key 0, disregarding
debug1: update_known_hosts: known hosts file /home/fleabeard/.ssh/known_hosts2 does not exist
scp: debug1: fd 3 clearing O_NONBLOCK
Sending file modes: C0644 2662367232 elementaryos-6.1-stable.20211218-rc.iso
Sink: C0644 2662367232 elementaryos-6.1-stable.20211218-rc.iso
elementaryos-6.1-stable.20211218-rc.iso         0%    0     0.0KB/s   --:-- ETA

In regards to this

The second rule “allow any to LAB net” is not needed, because traffic within the same subnet never hits the firewall, so anything in the LAB subnet can talk to anything else in the LAB subnet anyways. And even if this rule were necessary, which it is not, it would have to be placed above the “allow any to !RFC1918” rule in order to have any effect.

It seems that every YouTube video I watch on pfsense firewall rules have you do this rule. Even videos from Lawrence Systems. Not saying you’re wrong here (just trying to fill gaps in my knowledge), just curious why it’s in every guide/video I’ve ever seen around the topic?

Sorry, still not sure what causes this, but it’s definitely not the firewall rules. You have a wide open any to any rule on HOMELAN, so the firewall will definitely not block anything coming from there.

Yes I was partly wrong. You need to allow DNS to “LAB address”, if you’re using pfSense’s DNS resolver or DNS forwarder. if you have configured external DNS servers on your clients, no additional rules are needed.

All good. I’m just sort of glad it’s not a pfsense issue, but that leaves me at having a proxmox issue that I’m not sure how to troubleshoot. Thank you for all your help!