Netduino Plus 2 microcontroller has the ability to configure alternate function mapping for its peripherals, so the CAN interfaces can be accessed via pins D5, D6 (CAN1_RX on PB8, CAN1_TX on PB9), resp. D4, D13 (CAN2_RX on PB12, CAN2_TX on PB13).
The CAN interface on STM32F4 does not include physical layer transceiver, so I would start with that - popular option is for example MCP2551, or SN65HV series by TI.
Then, I would create a prototype application, implemented in C/C++, perhaps using one of the existing libraries, I think the standard peripheral library by ST already contains CAN driver. The reason for this is that .NET MF is large and significantly affects (slows down) deployment and debugging, also it is much harder to troubleshoot anything in such complex system.
Based on the overall evaluation of the application, I would decide whether it is needed to include the functionality in the .NET MF itself, or whether any alternative is better (leave CAN interface implemented on separate microcontroller/board, use SPI-CAN bridge (e.g. MCP2515) as suggested by NooM etc.). GHI Electronics has included CAN support in their Premium library (GHI.Premium.Hardware.CAN), this could serve as inspiration for designing the managed API. By the time you get here, creating a new .NET MF interop project and adding it to the firmware will be piece of cake...
Note: If the project is for automotive, then there are ready to use solutions available for a few bucks on eBay, those various OBDII cables and modules are basically CAN to serial/USB converters, usually with a micro to parse the protocols.
Welcome to the community!