Virtualised PfSense - How to PPPoE?

D

DlStreamnet

Limp Gawd
Joined
Mar 10, 2005
Messages
359
EDIT:

Got it working via passthrough and using a vSwitch - however I am maxing out at 9mbit?? Is there a way to test my connection speed to the router incase it's the LAN interface?

Hey guys,

I have virtualised my PfSense 64bit install, all is fine, installed VM Tools as we speak.

I bought a new 82579LM card, passed it through to the VM, and I am getting zero from it. No detection at all.

Therefore, how do I use PPPoE? Can I use one of the other NIC's that isn't on the LAN via vmnic1 or something?
 
Last edited:
Quick search says that NIC doesn't play well with pass thru or pfSense.
 
I don't pass the pNIC for the wan through to pfsense, just assign it to it's own vswitch and give that interface only to pfsense. Works fine with pppoe.
 
dave99 said:
I don't pass the pNIC for the wan through to pfsense, just assign it to it's own vswitch and give that interface only to pfsense. Works fine with pppoe.
Click to expand...

Any guides or tutorials for this? Complete noob.

I'm running through a switch if that matters.
 
He is saying he doesn't directly pass the NIC through to the VM. He just puts the NIC in a vSwitch like other uplink NICs. Just runs pfSense like a normal VM with virtual NICs. I do the same for Untangle.

If all that makes no sense then go buy a book on vSphere.
 
Maybe I am on drugs here, but I think the issue is the 82579LM is not supported - either by vsphere or pfsense (or much of anything else AFAIK).
 
Okay I found where I have gone wrong.

I bought an Intel 10/100/1000CT card and I received an 82574L - great, used this as my management NIC.

I bought another Intel NIC from the same supplier and received an 82579LM - fail.

This is what's thrown me lol. Going to go ahead and purchase a 82574L, lol.

Edit2:

Epic double fail, christ I need to take a lie down.

Turned out I had actually got the correct 82574L, I had just retarded out. All working, thanks guys.
 
Last edited:
------------------------------------------------------------

All sorted. Sorry for the waste of a thread, guys.

Quick Q though - I am now stuck at 9mbit - not sure if it's my ISP (I doubt it personally), but its definitely a brick wall at 9mbit.

Pass through limitation? Anyone got any success stories?
 
Sure you didn't get a 10Mb NIC? :)

You can push a lot of data..it's most likely not any sort of pass through problem.
 
I'd try removing the nic from passthru and add a new vswitch with that nic and give that vnic to pfsense and see what happens. what speed up/down is your ISP providing?
 
50Mb/s and I have no problem maxing that. I pushed 700MB/sec through a 10Gb NIC the other day..just through a VM like normal. You don't need to pass a NIC directly through to increase throughput. You can easily max a 1Gb or 10Gb NIC with vSphere doing it through vSwitches. Not a problem.
 
danswartz said:
I'd try removing the nic from passthru and add a new vswitch with that nic and give that vnic to pfsense and see what happens. what speed up/down is your ISP providing?
Click to expand...

40mbit, getting that fine through my pfsense dedicated box.

Will try the vswitch tomorrow I think!

NetJunkie said:
Sure you didn't get a 10Mb NIC? :)

You can push a lot of data..it's most likely not any sort of pass through problem.
Click to expand...

lol, yeah, my retard moment is over now - it's definitely a 10/100/1000mb :p
 
Mmmm

I have just set it up as a vswitch, and I'm still only getting 9mbit - what other trouble shooting can I do with this?
 
while it might be 10/100/1000, is it running at 1000, or only 10? I could be wrong, but I thought there was a glitch at some point with esxi not auto-negotiating correct speeds on some cards. Go to your vswitch properties and make sure it's showing 1000 Mb, Full duplex.
 
Hmm, 100mb/half? IIRC, that is the default if auto-neg fails. If the modem got 100mb/full, that could hose thruput.
 
Edit:

PfSense%20Slow%20WAN%20%281%29.jpg


2004943276.png
 
Can you do a 'netstat -statistics' (or whatever the freebsd syntax is) and print the IP stats?
 
do you have anything setup in traffic shaper in pfsense? that one has bit me before when upgrading speed.
 
Nope, vanilla install.

I have just installed the 32bit version on a fresh VM and same deal...
 
$ sockstat
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sockstat 19008 0 stream /tmp/php-fastcgi.socket-1
root sockstat 19008 12 stream /tmp/php-fastcgi.socket-1
root sshlockout 12743 3 dgram -> /var/run/logpriv
root login 12542 3 dgram -> /var/run/logpriv
root apinger 52073 1 dgram -> /var/run/logpriv
root ntpd 46255 8 stream -> ??
root ntpd 46255 9 dgram -> /var/run/logpriv
_ntp ntpd 43799 8 udp4 x.x.x.x:21391 213.154.229.24:123
_ntp ntpd 43799 9 stream -> ??
_ntp ntpd 43799 10 udp4 x.x.x.x:47210 194.238.48.2:123
_ntp ntpd 43799 11 udp4 x.x.x.x:32475 91.82.85.61:123
nobody dnsmasq 40683 3 udp4 *:53 *:*
nobody dnsmasq 40683 4 tcp4 *:53 *:*
nobody dnsmasq 40683 5 udp6 *:53 *:*
nobody dnsmasq 40683 6 tcp6 *:53 *:*
nobody dnsmasq 40683 9 dgram -> /var/run/log
dhcpd dhcpd 35637 8 dgram -> /var/dhcpd/var/run/log
dhcpd dhcpd 35637 12 udp4 *:67 *:*
dhcpd dhcpd 35637 20 udp4 *:63356 *:*
dhcpd dhcpd 35637 21 udp6 *:49458 *:*
root php 34056 0 stream /tmp/php-fastcgi.socket-1
root php 34056 9 dgram (not connected)
root php 34056 10 udp4 *:* *:*
root php 33871 0 stream /tmp/php-fastcgi.socket-1
root php 33871 9 dgram (not connected)
root php 33871 10 udp4 *:* *:*
root php 33871 12 stream /tmp/php-fastcgi.socket-1
root php 33618 0 stream /tmp/php-fastcgi.socket-1
root php 33618 9 dgram (not connected)
root php 33618 10 udp4 *:* *:*
root php 29942 0 stream /tmp/php-fastcgi.socket-0
root php 29942 9 dgram (not connected)
root php 29942 10 udp4 *:* *:*
root php 29689 0 stream /tmp/php-fastcgi.socket-0
root php 29689 9 dgram (not connected)
root php 29689 10 udp4 *:* *:*
root php 28416 0 stream /tmp/php-fastcgi.socket-0
root php 28416 9 dgram (not connected)
root php 28416 10 udp4 *:* *:*
root lighttpd 28111 10 tcp4 *:443 *:*
root lighttpd 28111 11 tcp4 *:80 *:*
root lighttpd 28111 13 tcp4 192.168.1.1:443 192.168.1.10:56523
root lighttpd 28111 14 tcp4 192.168.1.1:443 192.168.1.10:56522
root lighttpd 28111 15 stream -> /tmp/php-fastcgi.socket-1
root inetd 20235 10 udp4 127.0.0.1:6969 *:*
root logger 16695 1 dgram -> /var/run/logpriv
root syslogd 15818 9 dgram /var/run/log
root syslogd 15818 10 dgram /var/run/logpriv
root syslogd 15818 11 dgram /var/dhcpd/var/run/log
root syslogd 15818 12 udp6 *:514 *:*
root syslogd 15818 13 udp4 *:514 *:*
root devd 270 11 stream /var/run/devd.pipe
root check_relo 255 3 stream /var/run/check_reload_status
root check_relo 255 6 dgram -> /var/run/logpriv

? that's all I could find
 
Last edited:
Is this instance, yes - in my other VM (PfSense 02) - I have tried a VMXNET2 (Enhanced) for both LAN and WAN, and LAN/WAN respective
 
there is no 'netstat' command? that is standard with freebsd i thought? let me check.
 
Apologies, I thought when it was mentioned 'is there a netstat' that there wasn't so didn't try it.

Netstat -s gives tonnes of statistics, is there something specific I am looking for?
 
$ netstat -s
tcp:
1021 packets sent
732 data packets (550696 bytes)
0 data packets (0 bytes) retransmitted
0 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
261 ack-only packets (0 delayed)
0 URG only packets
0 window probe packets
0 window update packets
28 control packets
665 packets received
345 acks (for 549185 bytes)
25 duplicate acks
0 acks for unsent data
229 packets (72079 bytes) received in-sequence
1 completely duplicate packet (1 byte)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
0 out-of-order packets (0 bytes)
0 packets (0 bytes) of data after window
0 window probes
17 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded due to memory problems
1 connection request
27 connection accepts
0 bad connection attempts
0 listen queue overflows
0 ignored RSTs in the windows
28 connections established (including accepts)
27 connections closed (including 0 drops)
8 connections updated cached RTT on close
8 connections updated cached RTT variance on close
0 connections updated cached ssthresh on close
0 embryonic connections dropped
237 segments updated rtt (of 250 attempts)
0 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 Connections (fin_wait_2) dropped because of timeout
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
17 correct ACK header predictions
167 correct data packet header predictions
27 syncache entries added
0 retransmitted
0 dupsyn
0 dropped
27 completed
0 bucket overflow
0 cache overflow
0 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
27 cookies sent
0 cookies received
0 SACK recovery episodes
0 segment rexmits in SACK recovery episodes
0 byte rexmits in SACK recovery episodes
0 SACK options (SACK blocks) received
0 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
0 packets with ECN CE bit set
0 packets with ECN ECT(0) bit set
0 packets with ECN ECT(1) bit set
0 successful ECN handshakes
0 times ECN reduced the congestion window
udp:
738 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
149 dropped due to no socket
23 broadcast/multicast datagrams undelivered
0 dropped due to full socket buffers
0 not for hashed pcb
566 delivered
677 datagrams output
0 times multicast source filter matched
sctp:
0 input packets
0 datagrams
0 packets that had data
0 input SACK chunks
0 input DATA chunks
0 duplicate DATA chunks
0 input HB chunks
0 HB-ACK chunks
0 input ECNE chunks
0 input AUTH chunks
0 chunks missing AUTH
0 invalid HMAC ids received
0 invalid secret ids received
0 auth failed
0 fast path receives all one chunk
0 fast path multi-part data
0 output packets
0 output SACKs
0 output DATA chunks
0 retransmitted DATA chunks
0 fast retransmitted DATA chunks
0 FR's that happened more than once to same chunk
0 intput HB chunks
0 output ECNE chunks
0 output AUTH chunks
0 ip_output error counter
Packet drop statistics:
0 from middle box
0 from end host
0 with data
0 non-data, non-endhost
0 non-endhost, bandwidth rep only
0 not enough for chunk header
0 not enough data to confirm
0 where process_chunk_drop said break
0 failed to find TSN
0 attempt reverse TSN lookup
0 e-host confirms zero-rwnd
0 midbox confirms no space
0 data did not match TSN
0 TSN's marked for Fast Retran
Timeouts:
0 iterator timers fired
0 T3 data time outs
0 window probe (T3) timers fired
0 INIT timers fired
0 sack timers fired
0 shutdown timers fired
0 heartbeat timers fired
0 a cookie timeout fired
0 an endpoint changed its cookiesecret
0 PMTU timers fired
0 shutdown ack timers fired
0 shutdown guard timers fired
0 stream reset timers fired
0 early FR timers fired
0 an asconf timer fired
0 auto close timer fired
0 asoc free timers expired
0 inp free timers expired
0 packet shorter than header
0 checksum error
0 no endpoint for port
0 bad v-tag
0 bad SID
0 no memory
0 number of multiple FR in a RTT window
0 RFC813 allowed sending
0 RFC813 does not allow sending
0 times max burst prohibited sending
0 look ahead tells us no memory in interface
0 numbers of window probes sent
0 times an output error to clamp down on next user send
0 times sctp_senderrors were caused from a user
0 number of in data drops due to chunk limit reached
0 number of in data drops due to rwnd limit reached
0 times a ECN reduced the cwnd
0 used express lookup via vtag
0 collision in express lookup
0 times the sender ran dry of user data on primary
0 same for above
0 sacks the slow way
0 window update only sacks sent
0 sends with sinfo_flags !=0
0 unordered sends
0 sends with EOF flag set
0 sends with ABORT flag set
0 times protocol drain called
0 times we did a protocol drain
0 times recv was called with peek
0 cached chunks used
0 cached stream oq's used
0 unread messages abandonded by close
0 send burst avoidance, already max burst inflight to net
0 send cwnd full avoidance, already max burst inflight to net
0 number of map array over-runs via fwd-tsn's
ip:
73029 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled ok
2032 packets for this host
3 packets for unknown/unsupported protocol
70395 packets forwarded (0 packets fast forwarded)
8 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
2352 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
26 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header
Click to expand...

netstat -s ^^

Thanks for the help so far, buddy
 
Crossing messages. You want to look for tcp retransmits. What happens if you have one side thinking half-duplex and the other full-duplex, the latter will not be looking for collisions, so it can step on the half-duplex host. This will cause late collisions and other crap, which will result in dropped packets. For TCP, this will cause (lots of) retransmits, falling back to slow start (and screwing performance into the ground.) Try something like:

netstat -s -p tcp | grep retransmitted
(upload a large file somewhere and assuming you get slowness)
netstat -s -p tcp | grep retransmitted

and see if any of the counters jumped.
 
Uploading a 3GB file to my FTP and I am still on 0 retransmits...definitely not a collision problem by the looks of it.

I am now using VMTools package, fresh/vanilla 32bit install and VMXNET2 Enhanced adapters

$ netstat -s -p tcp | grep retransmitted
0 data packets (0 bytes) retransmitted
0 data packets unnecessarily retransmitted
0 retransmitted
 
Is there an ftp client in pfsense? If so, what speed do you get if you upload from the pfsense itself?
 
danswartz said:
Is there an ftp client in pfsense? If so, what speed do you get if you upload from the pfsense itself?
Click to expand...

Not sure how I would accomplish this, as there isn't much space on the datastore.

I have just phoned my ISP whom have said it is 100% syncing at the correct 39999Kbps (40Mbit) - to further place this problem on the ESXi5/Pfsense setup.
 
How big is your virtual disk? I guess if it's only a couple of GB and you don't want to create a scratch install with a bigger HD to test... Kinda running out of ideas unless you are up for using something like wireshark to capture a slow session and look for smoking guns...
 
I'm just thinking this must be a simple fix, I don't think it's collisions as it is at 9Mbit whether I use passthrough or not.

I might try out another distro and see what happens.
 
yeah, 9 mb just sounds like something is stuck at 10 megabit somewhere in the works. The interface in pfsense is showing 1000base-T full duplex, right?
 
Doesn't PPPoE have a smaller MTU or something? Can't imagine why that would cause this though.
 
dave99 said:
yeah, 9 mb just sounds like something is stuck at 10 megabit somewhere in the works. The interface in pfsense is showing 1000base-T full duplex, right?
Click to expand...

I agree completely.

I have no idea where to look in PfSense to see configuration for this. Can you help?

I have just set vSphere to force 100MB FULL just in case.
 
i was looking at the wrong int, doesn't look like there is a way to see link speed on a pppoe link.
 
You must log in or register to reply here.
Back
Top